they indicated they still wanted gzip to be considered specifically to increase “availability for low end systems as lzip isn’t that widely supported”:
Unfortunately I'm not quite seeing the use case here. If it's a low-end system that supports only gzip-style compression, presumably it is an end-use system that merely needs access to the data and it should get tzdataXXXXX.tar.gz. In contrast, the tzdb tarball contains code intended for use by developers, who are expected to have access to software tools like cc and lzip that a low-end system might not have, and developers can easily gain access to these tools if they don't have them already. If we were to start from scratch now, Zstandard (Internet RFC 8878) would be a good choice for distributing the data as it outperforms gzip on both speed and compression ratios (though it doesn't compress as well as the much-slower lzip), and my impression is that Zstandard is gaining in popularity. Perhaps we could start by encouraging the distribution of tzdata.zi in Zstandard format in addition to what we already distribute; to represent all of TZDB 2022a's data, tzdata.zi.zst needs just 24,604 bytes, which is nearly as good as tzdata.zi.lz's 22,460 bytes. One more thing. We shouldn't assume that iana.org as a utility that billions of devices can blithely access for time zone data. If you're building an IoT application for low-end devices, please arrange to have your downstream servers serve up time zone data. And if you do that, you can use any compression format you like.