Agreed. Raw threads are almost always the wrong application-level concurrency abstraction. Actors/Erlang-style concurrency and futures are both much better abstractions for application programmers. I'm also a big fan of threads with compile-time proofs against data races, a la Rust, but I can appreciate it's a lot to learn for many application programmers.
And in reverse, using threads won't prevent lock-ups: the opposite is likely. [Pre-emptive] threads compared to external processes require much more careful coordination that is hard to achieve if you are installing dozen of emacs packages written by different people that manipulate the same state.
unrelated, it is one of the arguments in favor of GIL such as in CPython--it is easier to get right than fine-grained locks.