The "CRC-32 is slow" sentiment feels like a bit of a straw-man argument against gzip. With today's computing power, the difference is nigh-unto negligible: checksumming is dwarfed by the actual decompression, or maybe even the network overhead/latency.
Gzip is, doubtless, better for the reasons laid out in the article, but why aren't we moving forward? Do any browsers support LZMA or bzip2? Would they be at all worth the effort? I assume not in the case of HTML/resources, but maybe in raw non-compressed binary streams.
The largest assets will be already compressed (eg images and/or video). Http compression is only really benefiting for textual content. Gzip gives you a massive space saving over non compressed for textual data, but after that you're in diminishing returns. Although bzip2 is better than gzip, its not a lot better.
bzip2 compresses significantly better than gzip (I typically see a delta of between 10% and 30% in filesize) but it comes at a significant cost: compressing/decompressing the same file generally takes many times longer. xz compresses even better but takes even longer.
Also, some web servers (or at least Apache) will serve gzipped static content automagically if it finds a matching gzipped file. For example, if you have /var/www/html/foobar.css.gz, it will serve the contents of that file directly when the client requests http://example.com/foobar.css. So if you're running a stock Apache configuration, there's no reason not to just run gzip on all of your static assets and get lower bandwidth bills right away.
How many raw non-compressed binary streams do you need to deliver? Most assets a Web page requires are textual (CSS/JS) or already compressed: images, video, Flash content...
You need to consider that once you add something, you need to support it for the indefinite future. So we need to give serious consideration to things that are added. Does LZMA provide a sufficiently large compression ratio over gzip? Does the compression and decompression time introduce a lot of latency, especially on mobile devices? Does that increased latency mean plain text is faster?
That's why we have the Accept-Encoding header. Neither clients nor servers would need to support alternate compression schemes, either now or in the future. But if they both did, maybe there could be some benefit.
That's the problem, one major browser implements it, then they all need to. Then we have servers and browsers that become more and more complex, not that that isn't the case already. Thinking carefully about whether something is a good idea is important. Personally I think compressing data with LZMA or bzip2 will introduce a lot of latency, more then the time to send all the data unencrypted; then lets not talk about needlessly wasting server bandwidth to encrypt it (it all adds up). Then you have spdy, which implements compression at a protocol level.
Gzip is, doubtless, better for the reasons laid out in the article, but why aren't we moving forward? Do any browsers support LZMA or bzip2? Would they be at all worth the effort? I assume not in the case of HTML/resources, but maybe in raw non-compressed binary streams.