Not sure how this didn't get more completely answered previously.
Bitcoin has not sent the full block as the primary propagation method for a couple years now, see BIP 152. What gets sent is the block header, 6 bytes per transaction, and the coinbase transaction. Optionally, additional transactions may be sent that the sender predicted the receiver won't know.
The very short hash is possible because the hash is salted distinctly by each transmitting node. This makes it impossible for an attacker to intentionally create collisions, and any collisions that happen by chance get 'routed around' in network propagation by virtue of the fact that blocks just flow faster on links where there wasn't a collision.
Because this message is so small BIP152 is able to frequently eliminate one round trip by not performing an INV. So the fact that an extra roundtrip is sometimes needed to fill in missing transactions only leaves it with the same number of round trips as the original protocol.
There is also fibre which unconditionally reduces the transmission to 0.5 round-trips, but at a cost of wasting a considerable amount of bandwidth. For fast links this is the fastest thing to do.
For the concerns of network security and stability, it isn't just a question of how slow propagation is on average but how slow it can be made by a miner in the first case. BIP152 does a great job on the average, but doesn't actually improve the worst case Also the amount of data in a block also controls the amount of data outside of blocks, at most compact blocks can only reduce the total bandwidth of a node to half over the original scheme.
BIP152's design was selected as a trade-off between many factors-- latency, bandwidth, computational load, implementation complexity. Fibre represents a different tradeoff (favoring the absolute lowest delay instead of less bandwidth). We know how to get blocks down to about 500 bytes typically, with considerably more implementation complexity and computation, but it doesn't seem like there is much cause to do so relative to the importance of improving other areas of the protocol. This is doubly true because these improvements don't help the worst case. I believe FIBRE already achieves very close to the best possible worst case performance.