how are C/C++ disproportionally hard? the concept of multi-threading is the same for any language that supports it, most of the primitives are the same, and it's really not a lot nor complicated code to implement those.
the difficulty totally lies in the design... actually using parallelism where it matters. - tons of multi-threaded programs are just single-thread with a lot of 'scheduler' spliced into this one thread -_-
Maybe the large number of standard library functions that operate on globals and require you to remember the "_r" variant of that function exists, or the mess with handling signals, or the fact that Win32 and Posix use significantly different primitives for synchronization? Or maybe just the fact that most libraries for C/++ won't have built-in threading support and you need to synchronize at each call site?
Unless I'm writing Java, I avoid multithreading whenever possible. I hear it's also nice in Go.
Go is kind of broken here, since multithreading is one of extremely few ways to cause UB in Go.
Rust is very much best in class here.
It is disproportionately hard to do multithreading in C and C++ because the blast radius is huge and the tooling is not good. Languages with runtimes (Java, C#, etc.) give you lots of analysis and well-defined failure modes (in most cases), and Rust prevents almost all related bugs through the type system.
In terms of effort or expense, making any C or C++ program multithreaded is at least an order of magnitude harder/more expensive, even when designed for it from the beginning, so lots of programs aren't multithreaded that could be.