I've personally never actually had any major problems with threads.

Other than looking up the relevant keywords on perldoc, a history of lurking and reading on perlmonks, and some basic knowledge of how computers work from university courses, it didn't take much research either.

For example, setting up a game with multiple threads, one for comms, one for physics, one for AIs - it worked well on the first try. All I did was start the threads at the beginning and share a couple variables. Keep data isolated to the thread that needs to know. Load the multimeg gamestate only in the physics thread, keep the player connection info in only the comms thread, and away it goes.

I'd also seen posts warning of the troubles of mixing threads and TK, but that wasn't really a problem either. There's only a couple options; load and/or init the TK stuff before and/or after spawning the second thread, and start the MainLoop() in one of the two threads. I know I had to try a couple ways before finding one that worked, but it wasn't painful enough of a process to remember off the top of my head. Looking at the code, it turns out I initialized the gui, then spawned the processing thread and detached it, then kicked off MainLoop(); in the parent thread.

Using threads takes a fair bit of computer sense to get right. My suggestion is simply to start small and minimalistic, understand what's going on, and then expand from there. You've still got to realize the basics, such as why a thousand threads is bad, why multiple threads writing to disk goes wrong, that starting threads is expensive, and that it copies memory when the thread starts...

So. I would certainly discourage the use of threads by beginners. On the other hand, for those who understand the fundamentals of How Things Work, threads shouldn't be much trouble at all. A blanket discouragement is not sensible to me. Threads are simply an advanced concept, and a fairly sharp blade in the tool chest.