If I have a problem that will benefit from concurrency, and doesn't need ongoing shared access to data, (and if I'm on a platform that has fork available), I'd probably use fork. Though, if no data sharing is required, then running independent subroutines in separate threads is just as easy to debug. Run each thread individually until it is (percieved) bug free and then start them all.

But there are a whole class of problems that need ongoing access to shared data.

Forked solutions to these problems mean serialising data and passing it (bidirectionally) through pipes or sockets, and that adds far more complexity and is even harder to debug than threads. Flattening and reconstituting compound data-structures is one problem. Coordinating bi-directional communications another. Synchronisation between processes is just as hard, and equally fraught with deadlocks and priority inversions as is synchronisation between threads.

All the difficulties of concurrency exists regardless of the unit of concurrency (processes or threads) used. The only difference is that when using processes, communications is slower and adds complexity. The only way to handle bi-directional asynchronous communications without threads, is to use a select model state machine. State machines are far harder to program than the linear flows that can be used when you have threads.