Brad Wilson writes:
"The so-far compelling reason to use HTML as an application deployment system is ease of administration. Unfortunately, I think the author missed the boat, because .NET has a really good story for client-server applications. Your client code comes from a web server, not the local disk, which means that it stays up to date. You control the server code just like you control the web application code. Zero installation, zero deployment, zero hassles. The pre-requisite of the .NET runtime is perhaps the sole stumbling block, much like having the Java runtime -- whose? which version? -- installed before being able to run Java in the browser."
[HTML's Time is Over, The .NET Guy]
We've had the whole WebForms vs. WinForms argument many times. For the most part, I am a supporter of using WinForms (at least in some cases) for exactly the reason(s) that Brad mentions.
There is no doubt that HTML is a crude delivery mechanism for applications, and building a rich client in the browser is never much fun - especially when it can be done so much easier with a Windows application. And now, with .NET's "one-touch deployment", you have the centralized deployment benefits of a web application with the Windows application's rich interface - the best of both worlds.
And not to mention state management is a hell of a lot easier...
A compelling reason for web-based applications, though, might be providing ubiquitous access from remote machines. Many companies have remote access solutions, where users can connect from virtually anywhere - from an unknown machine with unknown capabilities and unknown bandwidth. And as Joshua points out, .NET is not a reasonable cross-platform solution (yet).
The kiosk in the airport may have a web browser, but not the .NET runtime. Perhaps the kiosk isn't running Windows. If I can use a client-less VPN solution to connect and run my application, that's good.
If you have users connecting over dial-up, bandwidth might be a consideration too. I doubt that the executable is downloaded each time - I'm sure that it's cached and only fetched if something changed - but the difference in size between the HTML for each screen and the entire application (including business logic) is likely substantial. If you're on a thin pipe, that can be important.
Oh, and delivering to mobile devices is a lot easier using MMIT, etc. than writing a completely new application.
As always, there's no prescriptive solution for these decisions. Different applications have different requirements. I don't think you can unilaterally say that web-based applications are no longer necessary - at least not yet.