The problem with automatic and invisible update is this:
say you are using chrome in your company as the interface to an internal tool of some sort. Since the tool is used internally it's messy and one day chrome changes and now, automatically and invisibly, no-one can use it.
I'm not saying chrome's way doesn't have its upsides but there is also a good argument for mantaining older releases.
Point taken, but standard practice is to write correct code for a CSS bug, then write a 'hack' that works for that specific browser version.
On the other hand, if you're doing an intranet site with a company that only has one browser, you might have dispensed with writing correct code and only written the hack.
Its' temporarily practical in a time crunch, but not a good practice since the next update may kill your hack.
Note that there are also other cases where incompatible changes are made (e.g. ES5 is not exactly compatible with ES3 in various edge cases, CSS2.1 today is not quite compatible with CSS2.1 a year ago in edge cases, etc). The various standards groups an implementors try to minimize the damage from such changes, but it still happens at times.
Heck, Chrome 9 or 10, made major changes to the HTML parser to follow the HTML5 draft. Sites that depended on the old behavior (which different between browsers, so they presumably browser-sniffed and then sent different content to different browsers) likely broke. They certainly did in Firefox when Firefox changed to the HTML5 parsing algorithm.
This happens in the wild with Java updates. We have been burned twice with minor point versions that broke our app, that were pushed out automatically.
I'm not saying chrome's way doesn't have its upsides but there is also a good argument for mantaining older releases.