I don't agree, since the compressor can be tuned to the data you could just move some of the data into the "decompressor" and end up with an arbitrarily small "compressed" file.
He did "win" on a technicality: The challenge did not count the size of the filesystem metadata towards the sum, so he hid information there.
Also tuning the decompressor to the specific data-set was entirely allowed, even intended. Otherwise it would be obvious that the challenge is impossible, in this way it depends on a sufficiently random data set.
Regardless, it boils down to this: Do you feel the rules of the challenge forbid shifting an arbitrary amount of information from the compressed file into the decompressor?
If you could hold 400 bytes of executable code in memory without any additional information, feed it 599 bytes of memory and it outputs 1000 bytes - that's compression.
Anything else is just an abstraction around this.
His solution does not work because he is storing extra information in the lengths of the files, i.e., where to split the files and write a "5" byte. Preserving this in memory would require extra storage.