>> which works perfectly for a few dozens to low hundreds of threads

It's a lot more complicated that than. It depends heavily on how many threads are writing to the shared memory and how often. If the workload is write-heavy from many threads then then it can really add up. Also, if there are multiple shared memory locations which all use mutexes, it adds up as well. Shared memory offers diminishing returns as the logic becomes more complex.

Often, it's better to simply design the system in such a way that it removes or at least minimizes interactions and data sharing between different threads or processes. With such designs, often the overheads of IPC communication become very low.

Some engines like Node.js are focused around IPC as the main mechanism for sharing data between different processes. It produces relatively elegant code which is easy to follow and this design makes it relatively easy to identify the bottlenecks.

I agree that the approach I was suggesting is probably not ideal for low-concurrency situations (like games as I mentioned in my last comment) but I still think that shared memory access mechanisms are not elegant. That said, I find that programming solutions which try to squeeze every last drop of performance out of the hardware are rarely elegant architecturally.

In my experience it is very to easy get into situations where using only mutexes is impossible. As soon as you need a lock per object and access two objects then you have to make sure to only acquire one lock at a time. The end result is that you are effectively using the stack as a message queue that can only hold one element.

The solution with multiple locks is to always take them in the same defined order on any code path - that guarantees that you can't get into deadlock situations.