The different stations don't represent developers, they represent discrete tasks. So that could be designer > coder > qa, or dev stack 1 > dev stack 2 > dev stack 3. A coder waiting for a design won't just go and design. A developer with Stack 3 might be familiar with Stack 2 but might not know the best practices from that stack, introducing bugs or funky code that will create more work later on. If all your developers can do all the tasks, the graphics in this story don't apply.
As always: communication overhead. This developer coming in to a new thing after finishing their last thing has to spin up on all sorts of stuff, maybe they don't even know much about what we're working on, but even if they do, they don't know what the current status is. All that spin-up has cost both for the developer and the new team. It is often more efficient to spend that idle time working on lower-priority tasks in their current area.
You can't just break development tasks into subtasks at will, they always have a natural structure. Also, you can't go reassigning developers all the time, they should always do their tasks from start to completion or their productivity suffers badly. Neither can you assign several developers to the same task and get a productivity improvement.
If the problem is that some developers are literally idle because their task is done, they should do something else.