When you're starting from scratch, designing for multiple threads is relatively easy. When you're iterating on a previous design or your best practices from previous projects, it becomes very hard, because you need to move/refactor/redesign/reimplement a lot of code.

On top of that, you need to test it, which means it's much more time consuming.

>When you're starting from scratch, designing for multiple threads is relatively easy. It's not. Gameplay code changes constantly and always touches a ton of systems, it's very hard to parallelize, and load balance between cores.

I'd be surprised if any complex modern game had multithreaded gameplay code, and even if they do, it's usually some common, but CPU intensive problems, like pathing that gets parallelized.

Additionally, I found that most people don't have the skillset to write correct multithreaded code in any capacity, and even those that do frequently introduce hard to detect bugs, in addition to being a huge mental overhead.

It's even harder to make performance gains using multithreading. Let's say I multithread my code, but the additional complexity, and synchronization makes my code run at 60% the original speed. On 2 threads, I'm running at 120% speed. It would've been much easier to keep my code on 1 thread, and invest the mental energy to make the code 20% faster there.