Oh, targeting a good VM is a huge win over a typical machine language for an implementer. My prediction is specifically that the inter-language paradise some expect will never come.
But even within the points you bring up, I'm not sure that VMs are as winning as they're made out to be. Size and compilation time aren't somehow intrinsically better for VMs; JS does quite well on both fronts these days. And I'm not convinced JS's quirks are harder for implementers to cope with than a silicon machine language's.
At a technical level, virtual machines are not the panacea many folks seem to think.
Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs.
But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics.
Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best.
You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects.
Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.
If this were our (Mozilla's) strategy, it's hard to understand why we'd release our code under an open source license, and why we'd insist on every standard we implement being freely implementable by anyone with the requisite chops.
Mozilla "conspires" to do almost exactly the opposite of what you suggest. Having lots of decent browsers available was our old success condition. Now the mobile world is starting to look locked up, so breaking that open to competition and free choice is our new success condition.
I've been a participant in GNU since 1990. I've been a maintainer of GNU Emacs, GDB, Guile, and (briefly) EGLIBC, but many others have contributed a lot more than I have. Mlynarik's contributions to GNU are relatively minor. Calling him a "founding father of GNU" is a bit rich; it was pretty gratuitous of him to bring it up.
Note that Mlynarik could have made every single one of his contributions without verbally abusing anyone. It's not like you have to swear at someone to explain why you think something is a bug. He freely chose to add the abuse to his technical content. Since the abuse is utterly inessential, there's no reason to put up with it.
The abuse doesn't even express depth of feeling. He's always written like that, to pretty much everyone, in all circumstances. It's noise in his signal.
I think Mozilla is absolutely right to ban him from its sites. As someone said, "Sure, you have the right to be a jerk --- just not on my web site."
I'm amazed that HN readers are so backwards on this.
I don't understand why so many commenters on this thread consider verbal abuse a mark of sincerity. You can say everything you need to say without it. Mlynarik has pursued this style of interaction with people for decades, so it doesn't express any particular intensity of feeling; he just likes crapping on people. Maybe you don't mind reading it when it's not directed at you, but why should the recipient put up with it?
But even within the points you bring up, I'm not sure that VMs are as winning as they're made out to be. Size and compilation time aren't somehow intrinsically better for VMs; JS does quite well on both fronts these days. And I'm not convinced JS's quirks are harder for implementers to cope with than a silicon machine language's.