Juniors don't make decisions, they do analysis to support the decision makers. If a decision maker proposes something in the afternoon, he wants the analysis by morning to make the decision.
Good point. That's a good way to put it. Depending on task, unfortunately not everything is parallelizable.
But quite often, culture is the problem as well. If performance bonuses are large enough, people will compete with each other and will be at each other's throats over control of projects. Machismo and cowboy-like behavior is to be expected in some environments. I personally think those environments are toxic.
Anyway I see the a point about some tasks not being easily de-composible, but I think culture plays a significant role here as well.
We sorta do in some cases. If you've ever worked closely with an outsourced team (in my case, India) handling support cases, this ends up being almost exactly like working in shifts. We make sure to commit our code and update the bug/client ticket before leaving. Then someone on the India team can pick up the work from where we left off.
Of course, this was only used specifically for high priority cases that came directly via a client rather than a normal bug fix or feature request. But I think this reflects exactly how and when shifts should be used. Work that can wait until tomorrow doesn't need to be handed off to someone. Work that is urgent can be handled in shifts.