Edit: This somehow ended up in the wrong thread with the wrong post by jakj quoted, but I'll leave it as it somehow seems fitting.
What gets me is that there isn't even a legitimate reason not to make your program multi-threaded anymore. OpenMP is now heavily supported by Intel, Microsoft, the GNU Foundation and from what I understand, an implementation is being worked on for LLVM/Clang. It's so easy to write cross-platform multi-threaded code with it that it borders on ridiculous. It's also tasked based, and while people have their preferences for multi-threading style, it's arguable that task-based multi-threading is a superior choice for writing multi-threaded code that automatically makes use of more processors as they're available.
OpenMP isn't even the "slow hog" that it's made out to be by people more comfortable with pthreads or Win32 Threads. The fact of the matter is, threading is very hard to get right when you're manipulating threads at the system level. Libraries like OpenMP (which is actually a collection of preprocessor macros) and Boost can't optimize for every possible situation, but more often than not, they produce much faster multithreaded code than something that was multithreaded by hand. Again, some people are geniuses at this stuff, but multithreading is hard, and even game developers, who tend to be top of their game (no pun intended) can write some downright awfully performing code. A quick look at any number of high-budget games built on-top of in-house engines will testify to that (STALKER, etc.).
Even the age old problem of making code multi-threading safe is getting easier with task-based and other new paradigms of multi-threading. For a game like Minecraft, you could easily write multi-threading safe code that builds a single chunk. Easiest (if not the best performing) way of doing this would be to load all the data needed from disk at once. Then tell the game to use every available thread to take a piece of data corresponding to a chunk and actually generate the chunk, then wait for all other threads on the task to finish. Once all the threads finish, they remerge and you can do as you see fit with the data, as you're now back to a single-thread.
This really ended up going off on a tangent, but suffice to say, there's no reason not to multi-thread anymore. At this point it's either reliance on legacy code that's not multi-threading safe or laziness.
