Obviously the fundamental problem has to do with race conditions in IPC communications, which is not just limited to threads. However multi-threaded processes tend to have so much more than other cases in the way of sharing that they are more prone to those problems than other programs.
As for whether iThreads protects you, I have to admit that its very heavyweight approach leads to far less sharing than in most threading models, which does offer some protection. OTOH I'm far from sure that there are no race conditions left in the regular expression engine. Furthermore Perl's iThreads cannot protect you from the possibility that there are race conditions in various third-party C libraries that you might have loaded. Now you can claim that choosing to use regular expressions or third-party C libraries is a case of the programmer creating the problem. And to some extent that is true. But it doesn't much help the programmer who is trying to fit together black boxes and may not understand in detail what is in those boxes.
As for whether you'd be better off with a different approach, well on any *nix you can just use multiple processes, known methods of IPC, and you get similar facilities to Perl's iThread model with better performance and better protection. In fact Elizabeth Mattijsen managed to implement iThreads using fork, and from what I understand the result is the pretty much the same except that it is faster, less bug-prone, and uses less memory.