This isn't just about replacing JavaScript with a CLI VM. It is about replacing the entire web stack, from HTML, CSS, and SVG all the way down to JavaScript.
The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.
Doesn't this just push the problem up the stack one layer? Now the W3C needs to define a specification for a virtual machine that can implement all of the current web specifications performantly. If your VM is missing an API to perform some new form of user input (like multitouch) or a rendering method for a new standard (like webgl) you'll need to head back to a standards body to add more hooks, leaving us in the same position.
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.
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.
The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.