It seems to allow for more variation in languages. The only time you really need to worry about those other languages is when you're trying to load modules written in other languages. At least that's how it works in .net. You can have pretty significant semantics from language to language and as long as you don't care about other languages actually loading your modules then it doesn't matter. If you concede that the problems of the lang->il developer are essentially the same as the lang->lang developer, then shouldn't we evaluate the il option strictly on it's merits? Such as reduced compilation at runtime and smaller payloads over the wire? As well as, optimally, less quirks than a language like JS. Not to mention existing lang->il compilers would have much less effort to retarget their output to the new platform. It just seems like a huge win to add the vm layer as the base instead of a general purpose language in every way.
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.
