That's just not true. Or rather, it's not true in a convenient fashion. The "tried and tested" compression formats (gzip, zip, even bzip2) have good API support within a broad range of programming languages. It's much easier to write code to deal with a tar.gz file than it is to: a) ensure that the xz tool is installed; b) create a temporary directory; c) shell out to run the tool and check that it was successful; d) use the files; e) clean up the temporary directory.

If the only developer use of the files was "extract them from the command line and look at them" then I'd be fine with a relatively obscure compression format, but as developers tend to want to write tools to use the files - preferably without always having to go through the extraction process first - the benefit of wide interoperability trumps compression sizes, for me at least. And as we're only talking about a relatively small number of machines, a difference in compression size won't affect much network traffic.

Jon