Sadly we don't have lossless compression of all inputs, merely a subset of inputs whose content is somewhat predictable. There's no way to uniquely represent all of 2^m distinct input bitstrings using 2^n outputs where n < m. In practice we assume input that's typically used has some predictable and redundant substrings, and that makes compression a win on average. But if you try to compress a high-entropy bitstring (such as comes out of a good implementation of /dev/random with noise from hardware), you will find it gets slightly larger, because the compression algorithm has to resort to supplying a literal copy of the input plus some small metadata saying it did so.

No, the difference is lossless compression algorithms have a defined lower bound on how packed the bits can get. No such lower bound has been asserted here in terms of compressing your work, just the idea that you can drop 24 hours off the end of the week with no loss of productivity. Clearly 24 hours is arbitrary, why isn't Thursday a half day?

A more sound argument would be one with actual data and measurements about how reducing the workweek affected overall productivity of the team. Without that it's just opinions and guessing.

>No such lower bound has been asserted here in terms of compressing your work, just the idea that you can drop 24 hours off the end of the week with no loss of productivity. Clearly 24 hours is arbitrary, why isn't Thursday a half day?

No such lower bound is defined, but one need not be. The OP is merely stating that the lower bound is 32 hours or less. He's not dropping 24 hours off, merely 8 (or 9, that par is unclear).

As another commentor points out, the lower bound on compression algorithms varies by input. This is likely true here, too.