Java is the prototypical Blub. It's saddled with a type system that wasn't even state of the art in 1991, motivating gigantic enterprisey libraries of RequestSpecificProcessorFactoryFactory crud. The VM is the reason we grudgingly tolerate it where I work.
It may be "prototypical Blub," but it has attracted a lot of bright and effective programmers, including several top-ten finishers in the Google AI Challenge and many, many people writing oodles of useful, practical code. I think it's fair to say from history that if you want to get things done in a cool, nicely designed language, it helps if your cool, nicely designed language runs on a platform that is dominated by a popular Blub language.
Proof: If there's no Blub on your platform, you'll exclude the vast majority of people who might write useful code you can use. If there is a Blub on your platform, its popularity will ensure that the vast majority of useful code on your platform will be written in Blub, and first-class language status on your platform will be defined by ability to interoperate with Blub. Therefore, the best case scenario is for your favorite language to be a minor player on a Blub platform.
C is another Blub, so you aren't contradicting my point, but I would say that the reason C isn't a good replacement for Java is that C has no support for garbage collection. C and Java both have a large amount of valuable, working code that programmers can utilize from other languages, but a language written on top of C has to accept that whenever a C library is used, someone must deal with C memory management, either the programmer who writes the bindings or every programmer who calls the bindings. They may have to deallocate memory and they may have to reason about the lifetime of memory deallocated by library code. Scala programmers can call Java code with no such worries. If they wrap a Java API in a Scala API, it is only for style and convenience. A Scala programmer would not use a C library lightly, certainly not without bindings that ensured memory safety, and writing such bindings would require a lot of care.
The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code.
Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance.
P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.
