Increasing the "number of shots" per unit of time doesn't buy you anything if the shots you take yield proportionally lower output. For example, in the days of punchcards and batch processing, if you were unsure about the syntax of one line of code, you wouldn't have just run the compiler, as it meant wasting an entire cycle. So the productive output of one run of the compiler back then would have been much higher than one run of the compiler nowadays.
Also, hitting a wait-state on any one task doesn't necessarily block the programmer as a whole, and doesn't necessarily decrease that programmer's throughput. You could imagine a scenario where a programmer is on ten projects. Whenever they get blocked on project A, chances are high that among their other nine projects, there is some project B that became unblocked while they were working on A. ...so, in theory, the programmer would never themselves be blocked, they would always have something productive that they could do, and the throughput of an entire team or company could remain unaffected.
The reason why there's negative productivity impact to organizing work in such a way has to do with "context switching overhead" when a programmer needs to context switch between different tasks/projects, or, if you will, a kind of "cost of retooling" a programmer's brain to focus on a different task.
It's also a productivity trap for psychological reasons. On one hand, you have the positive psychological impact of "flow state" which requires immediate feedback. On the other hand, you have a situation where, every time you have to wait for something, it's an invitation to focus on a distraction instead of something productive.
And then, last but not least, the amount of time a project takes to finish (talking latency now, rather than throughput) is a function of how densely you can schedule the tasks that are on its critical path, and if the programmers are actually in a position of having to context-switch a lot to stay productive, then that would introduce a lot of wait cycles into the critical path, unless it were counteracted by deliberate planning of the kind which is extremely hard to do, unpractical, and would come with its own overhead.
I think it's things like that which Brooks must have intuitively grasped when he made that statement.