Be that as it may people have to realize the inherent limitation of multithreading on interactive applications like games: They simply can't just split work in pieces and call it a day. They have to sync to keep some sort of consistent timing one way or another. They might do it very strictly with big slow downs or very loosely with some jerking (which is probably the reason similar hardware solutions like SLI and CF stutter) or some games may simply be more accommodating to it, e.g. less syncing needed in an RTS since for a lot of the time you do not directly interact with parts of the game. But at the end of they day they have to sync and that syncing will inflict latencies.
In practical terms that often means a very slow single thread can slow down the entire thing (even if it might not be slowed down entirely to the speed of the slowest thread always) and in general there are slowdowns.
If you want a very practical coding example, and one of the first a game has to tackle is that say you have a thread that only deals with input. So it collects input from your mouse and collects input from your keyboard and then it has to inform the main game logic thread that you pressed 'k'. Now, it can't just barge in to say "hey, that dude presses 'k'". It can't because simply there is no way of knowing if the last time 'k' was pressed was properly processed. You can't just say "press k" when the other dude is on point of "ok, let me register tha... NO I PRESSED ANOTHER 'K'". "I KNOW LET ME FINISH"! You see, if you can't sync you will have that and a segfault.