Chrome is a free product that already achieves it's main aims, if chrome was a $200 browser or something I'd imagine it would have to conform to the big release idea to.
http://news.cnet.com/8301-13846_3-10106174-62.html
There's some resistance to using auto-updating software in enterprises simply because it's not the way things have traditionally been done, but IT departments are warming up to it. The huge pain of doing a major upgrade and the constant security fiascos that come from using software that's 5 years out of date are a major incentive for departments to switch to a model where individual changes can be canaried and tested in isolation before bringing down the whole enterprise. Google Docs is certainly having some measure of success in the enterprise arena, despite being a webapp with this development model. And outside of Google, Salesforce.com has revolutionized their market with a webservice-based enterprise app.
If say Chrome was your sole web browser and an update broke compatibility with a business process, who is responsible?
It's a constant struggle to balance the business needs of predictable use and the need to stay competitive with up to date products. Mainframes and WinXP's default browser will continue to stay until the benefits can be clearly shown to out weigh the risks.
I think that more and more, companies are realizing that the answer to this is "You don't."
Google Chrome is a good example. Instead of trying to figure out exactly what needed to be in the product, they built a kick-ass updater (which is now open-source). One that let them transparently and efficiently download and install updates whenever necessary, so they could treat desktop software like a webapp.
And then instead of having to coordinate hundreds of man-years of work, they can have small independent teams that crank out a feature, release it, see if the feature works well, and back it out if necessary.
The best way to deal with an O(N!) problem is to keep N small.