I disagree. Im currently working on a dvd authoring/recording application. The built in encoder has mutli processor support (im currently running dual amd 2800's). I cant imagine what you consider to be too complex because As far as mProcessor and mThreads none of it is even a challenge. The hardest part i find is writing out the DVD header format and recognizing the various tags (for multiple format support) as well as supporting several of the major recorders.
Syncronization and communication between multiple processes/threads is not a difficult chore its just a chore. It either works and your good or it doesnt and you hammer away at it until it does.
I think one such problem is the programmer themself. They start toying with the idea using a simple worker thread to handle some lengthy calculation (CRC on a 500 meg file for exmaple). Later on when they actually try to tie the two togethor making one thread pause while another is using a shared resource and so on it starts to get a bit more complicated. I find alot of programmers will mess with something for a short time and then move on.
Any thing you can code you can do so in a complex impossible to do way. The real problem isnt in threading its in the programmer using it.
I didnt say your professor wasnt correct only that he was partially so. There are several free applications out using threading and they do so greatly. Most of these apps are written by children (im 15 and i hang out with other younger programmers).
