If HTML was still just hypertext, which is text organized with links to other text, then the separation of data from appearance makes sense. But we happen to use HTML and other web technologies to create complex long-lived applications that are much more than hypertext.
Seems to me that the answer is to provide a real applications development environment. Not to shoehorn ever more crap into browsers.
I've called before for splitting Web functionality into several modes. I think it's fairly clearly the way to go, and is actually how development's been headed to a reasonable approximation for the past few years.
1. A reading / discussion oriented platform. The traditional browser, though with vastly better document management capabilities, and much simpler graphical presentation. Basically elecronic paper, similar to Pocket / Readability / Instapaper, or an eBook reader.
2. An applications development platform. Pretty much where the mobile space is now. There's Internet connectivity, and often Web elements. But what you get are freestanding apps.
3. Commerce. It's own space for security and privacy as well as function. You're seeing this with iTunes, the Play marketplace, and Amazon commerce apps.
4. Multimedia. Give me a freestanding player with its own queuing mechanisms. Again, pretty much the case on mobile.
What browser-based apps offer is a uniform platform for applications development. It's a HUGE revolution in applications space, and as much as it's frustrating to me (on both the user and developer/ops side), there's no denying its impact and significance.
Supporting a zero-install or minimal-install path, supporting all platforms from the same runtime, and providing instant updates to all users is tremendous. It's a large part of what's made smaller Web ISVs (SaaS) possible. Systems integration and platform support kill applications design in other contexts.
But those same features are also limitations. I've had multiple horrible app upgrades, apply massive amounts of styling to Web sites and apps, and _still_ run into compatibility issues, as a Linux user. And then there's the security profile.
There are a number of compromises possible, but pulling the "applications runtime environment" out of my "information delivery tool" seems an increasingly positive step.
Not that we haven't had attempts to provide that runtime, e.g., Java and ActiveX.
One problem is that the runtime itself cannot run as the same UID as the user invoking it. It's got to be fully sandboxed and separated, further by origin site or authoring authority. Possibly within its own VM. Trust of Web content is a real problem and one that will only grow.
Because no one application framework is already supported by the vast majority of Internet-capable devices, requires no "installing," and supports a standardized and ubiquitous system to link between applications.
