I've tried what you're suggesting in order to write highly concurrent multi-threaded applications. I've used frameworks that are supposed to handle all the details of concurrency and synchronization for you. Inevitably they have flaws in their implementations where either the framework itself exhibits UB/data races/deadlocks, or else the design makes it far too easy to write your own UB/data races/deadlocks.

The worst part is that these problems usually don't show themselves until your software has been running in production for thousands of hours, and then reproducing the problem to try to debug it is effectively impossible. I've had cases where I resort to building my C++ application in release with debug symbols and then run it inside of gdb in production. I haven't benchmarked the effect of running it in gdb, but I have to imagine it kills much of the value of even using a high performance language.

Now I exclusively use Rust for any new development, and it's never delivered any unwelcome surprises to me after deploying.