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.
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.