Old builds can take up a significant amount of space on disk, even though they
often take up very little space when tarred and zipped. For example, I have a
build setup where the archived build output takes up 164MB, but can be tarred
and zipped down to 8MB. This problem is most prevalent when there are lots of
small files being archived, as with JUnit and Javadoc output.

In the mailing list, the argument against doing this is:

https://hudson.dev.java.net/servlets/ReadMsg?list=users&msgNo=10279

"In most of the situations, I don't think it makes much sense for Hudson
to do such desperate disk conservation measure. It's much cheaper to fix
the problem by throwing more HDDs at the problem, and on modern file
systems, you can have file-system level compression, too."

Throwing more HDDs is a good solution in many cases, but here it can often be a
20X win to compress the output. That means a 20X difference in the number of
HDDs required.

The problem with file-system level compression is that it will typically also
apply to the workspace folder, which can have a nontrivial impact on build
performance.