I think the core conflict is synchronization overhead vs latency, no? If communication is too granular there's too much synchronization overhead, which can be fixed by buffering, which in turn increases latency. Game engines have been swinging back and forth over the past 10 years on this a lot. First the trend was to have a few "fat threads" (maybe input+gamelogic->physics->visibility->rendering) which ran in parallel but which were coupled like a pipeline working on the previous frame's data. Each pipeline stage meant one frame more latency. Add the rendering API/driver latency, plus whatever the display device adds, and suddenly games had something like 100ms latency or even more which is very noticeable. Then people started to make the game loop a simple sequence of subsystem stages again, but subsystems split their work on the current frame internally into small parallel tasks. It will be interesting what the perfect game engine architecture will look like for VR with its ultra-low latency requirements from sensory input to display update.
