From my perspective, which goes back to before I ever used Perl or iThreads, almost the last reason for using threads/concurrancy is performance.

The best reason is simplicity. It is just so much easier to code anything that takes a long time as a simple, linear subroutine, and then kick it off into a thread and let your main program get on with whatever else needs to be done.

The alternatives, like finite state machines are hard to code, and totally unportable even to the same OS on a faster processor. You take your slow, linear subroutine and break it into iddy-biddy chunks, carefully sized so that each one only takes as much time as you have available between doing the other things that need to be done, (like interacting with the user).

Move it to another, slower processor, (or just run another heavy process on the same machine), and your user interface is slow as molasses.

Move it to a faster machine and you either refactor all your stateful chunks into fewer, bigger chunks, or you waste half your cycles 'task switching' before it is necessary.

With threads, you write self contained, linear code, stick 'em in a thread and the scheduler takes care of everything else. The only time threads are a pain to debug is when people try to write them as a closed coupled state machine. Which is simply the wrong approach and easy to avoid.