The article agrees, as should anyone who understands encryption and compression: encrypted data can't be compressed, so encrypt-then-compress is pointless.
The article also covers why compress-then-encrypt is dangerous. But it's not a dichotomy. Those aren't your only two choices, you can also just encrypt and not compress.
If security is the top concern, making all encrypted messages the same length would be ideal as far as I can tell. That way, all you are giving away is an upper bound on the message size. Padding with random noise to a uniform length (with the payload either compressed or not) and then encrypting should be the most secure option.
The point in that case is to combat plain text (known value) attacks.
Precisely how the padding / extra padding is distributed within the data stream to be encrypted is also an issue. The goal is to make it very difficult to guess where data will be represented if you do happen to know the plain text.
A lot, possibly a majority, of the major breaks in crypto systems (certainly the interesting ones) in the past decade have been because of compressing before encrypting. If someone wants to compress first, demand that they justify the reduced bandwidth usage.
Compressing then encrypting gives you more effective compression and (somewhat) less effective encryption. Encrypting then compressing gives you more effective encryption and less effective (almost ineffective) compression. So, depends which one you want more. :)
Yeah, running an encrypted bitstream through a lossy encoder like CELP is going to sound pretty awful (i.e., the content will be completely unrecoverable.) The whole idea behind a speech codec is to simplify the frequency-domain properties of the data in one way or another.
People are missing the real takeaway from the article, which is that VBR speech compression has serious vulnerabilities that CBR codecs won't share. That part wasn't obvious.
