That is true, but it is much easier to accurately implement a VM spec correctly than complex high-level specs like CSS and HTML, which leave a lot of ambiguity. New hardware interfaces are also a lot easier to specify when you're talking about functions which are rarely going to be called directly by human programmers, since they will usually be accessed through higher-level frameworks.
Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.
Complex VM? New UI metaphors? ...W3C? Sure, that spec oughta be ready in 20 years or so....
It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.
I think the idea has merit, but the current landscape of software development highly favours the statically compiled C++ browser engines, especially on mobile devices.