Not really, encoding (compression) is first and foremost about saving bandwidth. And bandwidth is sometimes limited, for the same reason your Wi-Fi network gets

Not really, encoding (compression) is first and foremost about saving bandwidth. And bandwidth is sometimes limited, for the same reason your Wi-Fi network gets slower as you get further from it, or if interference is received (microwave, neighbors downloading, etc). You have no choice but to reduce bandwidth, or start losing data on the link. Instead, you'll transmit more parity data, and maybe switch to less sensitive encoding schemes. Depending on the bounds you expect to be working in (ie, 10-100 Mbps is more comfortable than 3-5000 kbps), you pretty much need variable bitrate codecs to gracefully handle the (often temporary) bandwidth dips. Everything is a tradeoff: frequency ranges could be enlarged to increase bandwidth at the cost of interference, transmission power at the cost of energy efficiency and interference. And you can't do a lot (except beamforming) against propagation losses, so expected ranges have to be taken into account as well. It is true that the above makes less sense if audio is transmitted ahead of time, which makes it not latency-sensitive. By then though, why bother with that specific encoding? You're usually limited by memory on the receiving side, however.