And just to add that those two don't make sense together either so no one should have any thought of seeing that as supported option in future. Simply encryption make such changes to data structure that is hardly possible to compress that. That also means that encryption is compressing data by itself. If you don't believe it download somewhere from net some mime/UUE programs and make simple test. pgp or gpg will do too.

Now the only question is if encryption is done on client level or server side - I never tested that. I assume that if that happens on client side everything is clear. If it happens on server side that obviously larger amount of data is transferred across network so those who were using compression before and want to encrypt data now would not find it friendly. But I assume AES encryption takes place on client, but I never verified that.... (and even if it would happen on server side that it would soon be addressed with inclusion of avamar storage nodes which is next big thing to happen in NW world).

Correct.

That means that if data is encrypted, it would not compress. Ex. 10 MB of non-encrypted data may get compressed to 2 MB but 10 MB of encrypted data might not even get compressed at all or may be to 9 MB.

We are applying thie directive on server side.

Would it be OK to apply the directive on server side and use hardware compression?

Yes even not much of compression would be done with encrypted savesets (less than 5% I suppose). However other savesets (not encrypted) would benefit from that.