Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. That's mainly perception from when I briefly worked with Enterprise Java many years ago --- no one wrote "simple" or "elegant" Java applications, and stuffing as many design patterns and abstractions in as you could was considered "best practice".
There are certainly examples of simple and small Java applications (see https://en.wikipedia.org/wiki/Java_4K_Game_Programming_Conte... ), and I've written a few, but the overwhelming culture seems to be that of anti-optimisation and bureaucratic excess. In some sense, it's almost like working against or "challenging" the JVM's optimiser is the norm.
In my experience, a "simple, elegant" design --- which does not necessarily mean "highly abstract" --- tends to be very close to optimal anyway, with the compiler's optimiser doing the remaining work. That makes me wonder whether claiming a language/runtime/compiler has powerful optimisation abilities is actually a reflection of how much the typical source code in the language has to be "cleaned up" by the optimiser in order to be decently efficient.
Also, does anyone else notice the "Machine code" given for the JIT example is completely unrelated to either the Java or bytecode? It's 16-bit realmode --- I recognise the access to the 40h segment, it seems to be timing-related, and a bit of Googling finds that it's actually part of an old TSR clock utility (with unknown source):