Please don’t think of me as an expert, because the sum of my knowledge comes from browsing Wikipedia articles. But the summary of the issue is that Bluetooth gets all its energy efficiency and robustness by constantly scanning the spectrum it is to live in, and hopping around extremely fast to different slices of channels, essentially taking advantage of the tiny “gaps” in other signaling protocols that share the same free spectrum. In other words it operates on sloppy seconds/scraps like a vulture, which means it’s timing is very loose and cannot provide any guarantees. But it’s very low power as a result because it almost never has to shout over anyone else.

As callalex mentioned, the spread spectrum could introduce some delays into something like first packet response but this isn't necessarily the crux of the issue. Once a channel is being used, it can often stick around on that particular channel for a while so subsequent packets wouldn't necessarily have to do the whole spread spectrum dance until the devices start experiencing issues. IIRC there's some amount of stickiness to the spread spectrum utilization, but I could be wrong.

You're a tad bit incorrect on Bluetooth round trip a few centimers being 150+ms. Plenty of game controllers operate on or on top of Bluetooth and do not have 150ms latency. Headset Profile (HSP) bluetooth also does not (usually) have 150ms+ latency, usually more along the lines of maybe 30ms latency while many Bluetooth controllers will have <10ms latency.

https://www.reddit.com/r/RocketLeague/comments/8wvf9u/contro...

I'm not the person who designs codecs, but I'd wager most of the lag seen with Bluetooth audio systems come from the codecs. Bluetooth devices are often incredibly power constrained, so codecs operating over Bluetooth are usually trying to balance quality with computational complexity and dealing with packetization of the audio. When you're listening to an audio stream, it appears like a continuous stream of data. In reality, its chunks of data. You're listening to a previous chunk of data while the device is waiting to get the next packet, apply error correction to it, decode the very highly compressed data, and have the waveform ready to go out to your ears all on usually pretty cheap and highly power constrained equipment. It then has to be a bit tolerant to the above mentioned spread spectrum and a potential dropped packet here and there while still seeming to just be a continuous audio stream.

So in short, there's latency in a lot of Bluetooth audio codecs because the designers of the codecs felt the latency tradeoff was acceptable given the bandwidth, compute, power, and quality envelopes based on technology available at the time of crafting the codec.

Meanwhile, you're sending out pings on a device with keys on the keyboard bigger than the battery on a lot of bluetooth headsets with many orders of magnitude more processing power whose wireless connection is not normally that much of a power concern encoding/decoding extremely basic data to one of the companies with the most privately owned fiber with billions of dollars of computing equipment.