You're definitely right about the (probably huge) speed loss, but don't forget that parrot-compiled languages will be able to use each other's libraries. So, even though I couldn't imagine anyone running a pure-java app on parrot, I could see a lot of people wanting to take advantage of the huge number of Java libraries out there.

I'm more likely to want to take advantage of perl libraries from within Java. I have no doubt that there are a lot of high-quality Java libraries available, but finding them is made too hard because there's no JPAN.

Well, thats a whole 'nother ball game right there. To make parrot/perl libraries to java, one would have to pretty much re-implement much of parrot in java or java bytecode, kinda like how Jython works. Why? The Java bytecode spec is very sparse; to support things like closers, and eval, and other things not natively in java, one heck of a lot of plumbing would be needed. (For instance, parrot has something like a bajillion opcodes, while the JVM spec has under 200).

It considers highly dynamic languages as first class citizens, and all other languages will pay overhead whether or not it makes sense for them.

The .NET Common Language Runtime is pretty much the other way around. It seems much better suited to more static languages. I suspect that Java would more likely migrate there than Parrot. It will be interesting to see when Parrot is finished how it will compare against the CLR.