The argument here is evaporation cooling.  Low bandwidth miners spend more of their 10 minutes downloading.  If it takes 1 extra minute to download the new block, then the low bandwidth miners are 10% less efficient.  They go bankrupt and the block size increases again, and then another layer dies, until just a core remains.

However, "miners" are really validators/block creators on the one hand and hashers on the other.

The pool administrators are the validators.  The group that does the hashing is separate.

So, what you are worried about is a pool operator or group of them getting > 50% control.  In that case, the people doing the hashing could direct their support to a different pool.

Also, even if they were purely profit orientated, they could pool hop.  For the first minute, they could direct their power at the high bandwidth pool.  Once then 2nd pool had a new block generated, they could switch to that.  This would allow support for the outsider pool, with little negative effect to the person running the hashing system.

The pool connection protocol should probably have something like that anyway.

Server sends: "New block generated: please hash against this header

and nonce "

Server sends: "Block is stale: stop hashing, no further credit will be given for meeting target"

Server sends: "New block generated: please hash against this header

and nonce "

I think at the moment, the server can say that a new block has been found, but that doesn't tell the hashing software to halt hashing.  It just gets it to ask for a new header to hash.

A hasher could connect to multiple pools and set his software to prioritize certain pools. 

If the margins got tight enough, hashing engines might be put into standby for a few seconds while even the fastest pool has no new block available.  However, if you were connected to the winning pool, then they should be very fast, since no verification of the new block is required.