bzip2 and xz have had the potential to replace gzip for the vast majority of users and use cases since more than a decade - and in many cases they have.
What I'm trying to say is that the excessive focus on cutting-edge technology is holding back progress.
gzip is still the default compressor people use when they are not sure about the appropriateness of other compressors in their specific use case, and they don't have the time or energy to find out. To replace it, the a compressor must satisfy two requirements:
* It must not be substantially worse than gzip on any relevant metric. bzip2 failed this by being slow.
* It must be ubiquitous enough that the idea of installing it no longer makes sense. xz never reached this point, before people started replacing it with better compressors.
I think these arguments are a bit contrived. bzip2 made progress on compression ratio. xz (and zstd) made progress on both compression ratio and speed. Neither hovered around the idea of cutting-edge "technology" (they all fall into the same technology: general data compression algorithms) because they aren't niched oddities like e.g. paq. But I don't understand why a successor must trump gzip in both aspects. gzip certainly didn't trump all of its predecessors on both aspects, and both aspects take turns being the more important one depending on user and scenario.
By cutting edge technology, I meant the latest products that are better than the earlier ones.
I work in bioinformatics, where people typically use either gzip or domain-specific compressors. gzip is used for the reasons I mentioned. It works, it's usually good enough, and if people in another organization you've never heard of want to use your compressed files, they can do so without bothering you with support requests.
zstd would be faster and compress better, but because you can't be sure everyone else can use it, you don't even bother thinking about it. The saved computational resources are probably not worth it. On the other hand, anything that makes gzip faster is valuable, as it allows saving computational resources without taking any interoperability risks.
I didn't say the gzip replacement must be better than gzip in every aspect. I said it must not be substantially worse. bzip2 was substantially worse, because it was substantially slower.
bzip2 and xz have had the potential to replace gzip for the vast majority of users and use cases since more than a decade - and in many cases they have.