I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the top 0.5% programmers can handle. It's not that bad you know... If you're a half-way decent programmer and don't litter your single-threaded code with globals, shared memory and functions with side-effects, like you shouldn't anyway, parallelizing it after the fact to at least is usually pretty straightforward even. Maybe not optimal, but safe, and faster than single-core on multi-core hardware.

Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases.

I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.

The challenge is to design your code in a way that either makes it impossible to end up with race conditions or non-deterministic behavior, or if at least limit the number of possible points-of-failure. This requires a good understanding in what coding styles and data structures to avoid or pay extra attention to, but if you're aware of the pitfalls, it's actually not all that difficult. Just make sure your workers don't share any state, collect their outputs in a single thread-safe queue, use off the shelf components to represent threads, thread pools and locking mechanisms, be aware of things like multiple-read-single-write locks, and if you really can't avoid writes to shared state, only then start thinking about mutexes or semaphores. If you're smart about how you set up the code, more often than not you can get away with just some thread-safe queues. Take a look at Objective-C's block syntax and GCD for example, it makes maybe 90% of tasks suitable for multithreading dead easy.

Your estimate only 0.05% of programmers could write reliable multithreaded code is extremely pessimistic, cynical even. I almost feel flattered, having written a fair amount of multithreaded code that works perfectly myself, but I most definitely would dare count me with the 0.05% top programmers or whatever. My estimate is that with proper preparation, at least 50% of all programmers could learn to write reliable multithreaded code, and the remaining 50% probably wouldn't have a use for it anyway.

I was talking about the percentage of existing programmers with the abilities to pull it off. I'm sure more than 0.05% have the potential to learn it eventually, given enough time, motivation and opportunity. Like musicians & theremin!

You're making writing multi-threaded code sound like a herculean task. Sure, doing MT with mutexes is a pain, but programming with actors (message passing) is simpler. You can easily scale this for variable number of cores.