The combination of using Java and being coded naively means that there's a huge amount of pointer chasing and unnecessary dynamic memory allocation that can be easily cut out without even needing to dip into the data structures and algorithms literature to try for asymptotic improvements. There's no SIMD and no concern for cache locality. Last time I checked, it didn't even look like terrain generation was done in a separate thread from the interactive game logic, let alone in multiple threads. The game only simulates dynamics within ~128 blocks of a player, but if you've got two players miles apart they're still simulated on the same thread.

I do fully understand that the dynamic modifiability of Minecraft's game world means that it is always going to be hungry for memory bandwidth and will be latency-sensitive. But that doesn't mean it has to be inefficient. The Pocket Edition (not Java) already showed that huge improvements are possible, because they were necessary to get anything resembling Minecraft onto mobile platforms. There's a lot more that can be done when you're back on a platform that has sufficient RAM capacity and a ton more CPU power relative to RAM speed. There's a lot of latency that can be eliminated and a lot more than can be hidden from the user without breaking the game. The development process meant that hardly any of the early fundamental implementation decisions were made with the much later features in mind.