Clearly for software and service vendors responsible for distributing applications to several thousand clients, web applications must have seemed like a gift from heaven. No more installation wizards crashing, no COM registration, no DLL hell, no reboot, no desperate customer calls on the service hotline. And the same is true for regular software patches - updating a web application happens once on the server and that's it. Many CTOs even favor web applications for intranet scenarios just because of this single reason. When they have to decide between a thin and a rich client approach, it's quite clear which direction new projects tend to go...
The thing is, those folks succumb a fatal misconception. They are just so accustomed to the way traditional client software deployment has looked like for the last 15 years, that they lost track of what is possible today. There is absolutely no technical reason why a desktop application couldn't be installed and updated in a completely transparent manner as well. Off-the-shelf solutions like Sun's Java Web Start or Microsoft's ClickOnce (formerly known as NoTouch-Deployment) have been around for several years, and even if they weren't, there is no obstacle to a proprietary approach - just let your application check it's version number against a central service, and trigger an update if needed.
Now I am not proposing that eBay or Amazon should go for a rich client ;-) But I have watched a lot of intranet systems fail when it comes to usability, just because they were forced to go the HTML way (Ajax and Web 2.0 might improve the situation here, but the base principle still stands). Desktop applications can offer a much more sophisticated user experience, as well as taking advantage of the local machine's CPU power and offline capabilities. And on the intranet it's perfectly appropriate to communicate with an application server using DCOM or IIOP. When HTTP is a must, we still have webservices.
In my experience, developing a certain featureset for a thin client also tends to take more time than for a rich client and is associated with larger technical risks due to increased complexity (caused by the statelessness of HTTP or issues like server scalability).
Don't get me wrong, I like using and developing web applications - I worked on an internet banking solution for about four years, and enjoyed every minute of it. At the same time we implemented an enterprise banking system for corporate customers, where we went with a rich client. Both approaches were well-suited for each task and each particular end user group.
I am just afraid that unless decision makers learn about the real pros and cons of rich and thin clients, we will continue to see corporate intranet web applications spring up like mushrooms when desktop applications would have been much more appropriate.
