True, but you could compress then encrypt.

There have been what’s called “compression oracle” attacks on SSL with compress then encrypt scheme, see CRIME

https://en.m.wikipedia.org/wiki/Oracle_attack

An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist.

Compression is often not recommended in VPNs.

OP said the other way around. We all know encrypted data does not compress well, but why would you need to disable compression when encrypting? Compressed data should actually be a smaller dataset hence encrypting it should be even faster.

In general, if the size is then visible after encryption, you can tell that the data, whatever is was, compressed well. This is information leakage, and can, IIUC, be exploited to surprising degrees.

This doesn't make any sense. Here you have a disk. It's compressed or not, doesn't matter, the size stays the same. Then you use BitLocker on it. Again, compressed or not, after BitLocker encrypts it, the size is still the same. Your point?

Compress then encrypt opens up one important vulnerability: if an attacker can control a part of what you're encrypting (which they perhaps can on an average laptop drive, think a cookie in a webbrowser), and they can observe the size of the message after it has been compressed and encrypted, then with repeated attempts they can guess part of your secret and wait until the compression algorithm succeeds in matching part of their data with your secret.

TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.

Like I said, “if the size is visible after encryption”. I don’t know if this is a huge issue with block device encryption in general, but then again, OpenZFS isn’t really only a block-device-level driver, is it? I would not be surprised to hear that OpenZFS somehow encrypts on some higher level than the whole block device.