Building a web application is absolutely more complicated and harder to build than client-server, for a given set of features. There are a variety of reasons and ideas I'll describe in no particular order.
The highest voted question of all time on this site is What technical details should a programmer of a web application consider before making the site public? In there, there are dozens of bulletpoints, and while a handful are general statements, the vast majority of them are indeed specific to web programming.
Where is the "What technical details should a programmer of a desktop application consider before making the site public?" question? Why doesn't it exist? Because everything that would be in that list is inherent to programming in general, and web programming has to be concerned about all of those in addition to the aspects in the linked question.
Let's compare similar aspects of applications that are both web-based and not. In my opinion, the difference between client/server and desktop applications is insignificant compared to the difference between those and web based.
- Compare Google docs or Office 365 to desktop MS Office*. MS Office 10 years ago, (probably even 20 years ago Office 95), is miles ahead of both of them in terms of features and capability, with the exception of the simultaneous editing parts.
- Outlook + Exchange from years ago is superior to any web-based email client today.
- A lot of software is just straight up impractical or impossible to implement in a web-based offering, whereas anything that can be computed can be made into a desktop app. Nothing on the web cannot be implemented in a client/server app (besides stuff that explicitly requires a browser or runs in the context of an existing web site.)
The reason why the differential in capabilities is because web-based applications are so much more difficult and complex to build.
Browsers and the HTTP link adds significant complexity to web applications. Unless I am writing software to fly the space shuttle, I don't have to worry about an error 404 when trying to access some memory address or other resource, but web applications I often do. Losing total access to the disk is often not a significant concern for desktop apps, and gracefully crashing is usually considered appropriate enough. Losing the network on a web app not only happens often, and repeatedly, but is expected to be handled gracefully and resume connection. That's all on top of all the problems that can be happening inside the serverside or front end code.
The connection between the browser and http server does not maintain any significant state. In client/server and desktop apps, it trivially maintains as much state as you want to. Think of the dozens of frameworks and mountains of boilerplate for web frameworks trying to bridge that stateness gap in a sensible way. Thick client apps, you get that all for free.
Think of all the millions of person hours people have spent struggling with obnoxious gotchas in displaying sensible webpages, the days of making things line up in Internet Explorer. While desktop apps have plenty of gotchas as their own, I don't think something as seemingly simple as "making two columns the same size" has sucked so much of humanities work on the desktop as it has on the web. I think making stuff work cross-platform has been considerably easier than cross-browser.
Even if you try to cut down on some of this complexity by restricting what browsers people use, you can similarly tone down complexity of thick-client apps by restricting what OS they are using. The web app will always have more independently operating parts and will therefore result in more complex software.
Lastly .NET has no bearing on any of this, these are broad statements I believe to be true across all languages.
P.S. Obviously there is the "browser plugin" route but that basically combines the worst aspects of both so pretend that doesn't exist when trying to grok the ideas here.