Minecraft never was exclusively single-threaded - even a single-threaded Java application will have many other threads used by the JVM itself, including tasks like garbage collection which should run concurrently to avoid stalling the application. Even prior to 1.3.1, which split the game logic off into its own thread (the internal server in singleplayer), the game still had threads for tasks like file and network I/O (a must for any "real-time" application). Indeed, I see three out of four cores being utilized by 1.6.4, and that is before Mojang moved chunk rendering (incorrectly referred to as "chunk loading" but this has nothing to do with loading chunks from disk) and mob pathfinding to their own threads (in 1.8) and world generation (in 1.13), and probably more.
In fact, the JVM uses around 16 separate threads to run 1.6.4 and there are additional threads not normally active, like when the game is downloading a skin (this is why there may be a delay before a custom skin appears in-game):
Ironically, despite the updates to increase multithreading newer versions, especially 1.13+, perform significantly worse; I've seen poorly implemented multithreading as being a reason, plus certain things are still heavily dependent on the main threads and Mojang hasn't been exactly good at writing optimized code (if anything, all the rewrites they keep doing do the exact opposite; what was once a simple method call is now a chain of half a dozen or more calls to many different classes scattered all over the place, plus multiple hashmap lookups and object allocations; you can see one example at the end of this post. Because of this, a faster per-core performance is likely still more important, but multiple cores are also important (according to sp614x at least a quad-core CPU is required for good performance in modern versions).