I feel it's too harsh to downvote you (so I didn't), but you've pretty much admitted that you don't have enough information to speculate - perhaps you shouldn't. It's not about system software supporting threads; it's about user code not being thread-safe in the presence of hardware parallelism. There are some multi-threading bugs that never show up without it.
Right, but it's extremely difficult to get concurrency right at the application level. Anything that works usually works by chance, and changing the hardware that a multithreaded program runs on is a great way to find out how you fucked up the implementation.
Right now, it's likely that a lot of bugs are not showing themselves regularly, so nobody has bothered running any diagnostic tools (Helgrind, etc.)
I agree with you that people are really bad at concurrency, but I disagree that it's that hard once you get used to it.
Once you deal with one large deep difficult highly concurrent project, you get used to the idea that when there are threads and mutexes involved you have to think REALLY HARD about how it should work, and you can't rely on just trying something and testing it like you can with normal code. And if you do that, you can get threads to work pretty reliably, not just by chance.
