I strongly suspect that it's a bunch of "machine learning" hooey. If your compression is capable at all, it should be able to spend a few bits on categorizing what the "format" type stuff he's talking about is, and then do pretty much equally well as whatever specialized compressor. I won't say it will never be useful for some kind of data that has patterns and regularity that are not immediately obvious unless you spell it out for the compressor (2d images where there are similarities between the same positions on consecutive lines widely separated in the bytestream for example), but my guess is that this is a bunch of hype and garbage.
Just out of curiosity, I downloaded it and did the quickstart to test my assumption. Results I got:
$ ls -lh reads*
-rw-r--r-- 1 billy users 27M Oct 19 15:14 reads.csv
-rw-r--r-- 1 billy users 4.2M Oct 19 15:15 reads.csv.bz2
-rw-r--r-- 1 billy users 6.7M Oct 19 15:16 reads.csv.zl
So yeah I think at least at first look, for general-purpose compression it's trash. IDK. I also tried exactly what it sounds like their use case is, compressing PyTorch models, and it's kinda cool maybe (and certainly faster than bzip2 for those models) but at best it seems like a one-trick pony.
$ ls -lh optimizer*
-rw-r--r-- 1 billy users 76M Oct 19 15:26 optimizer.bin
-rw-r--r-- 1 billy users 56M Oct 19 15:27 optimizer.bin.bz2
-rw-r--r-- 1 billy users 53M Oct 19 15:26 optimizer.bin.zl
I feel like maybe building Huffman trees based on general-purpose prediction of what comes next, and teaching that how to grasp what the next bits might turn out to be based on what has come before including traversing different formats or even just skipping backwards in the data by specified amounts, might be a better way than whatever this is doing. But doing way worse than bzip2 for simple textual data even when we give it the "format hint" that it's looking for is a sign of problems to me.