Compression before encryption can leak information in a few ways.
Compression occurs on the plaintext, encryption is on the result of compression, and then there's a public and quite precise relation between size of result of compression and size of ciphertext (including if there's also compression in the encryption, as is the case by default in GPG, an implementation of (Open)PGP). Therefore the size of the result of compression of the plaintext is known to great precision (often, exactly) to adversaries. So is the nature of the compression. And that leaks some information about the plaintext. Some examples:
- If the plaintext is known to be constant length, that tells it's compressibility, and that's an important information. In particular, for voice truncated into short constant-time frames with audio compression, as in VoIP, according to this 2008 paper that can be enough to discern some phrases! And as the saying goes, “Attacks always get better; they never get worse” (attributed to the NSA by Bruce Schneier).
- Similarly, if long text messages are broken into separate segments of mostly fixed size and they are individually compressed, it will me possible to distinguish some features of the text (like what alphabet is used, or which of two different persons wrote it, if they have different typing habits).
- For photographs, size of ciphertext is an excellent indicator of which of several images was sent, and compression kills attempts to hide this by making the images of identical size. Even if such images are sent a single time, things like if they where on focus or not, or if they are taken at day or night, are likely to leak.
When using pure encryption (e.g. a block cipher in CTR, CBC, OFB mode), adversaries can alter ciphertext, so that altered compressed data will reach the de-compressor on the receiver side. Depending on de-compressor and alteration, the de-compressor can crash (that's common, and is often enough for a so-called Denial of Service attack), abort with error which perhaps can be sensed by adversaries, or output corrupted data which perhaps can leak in part to adversaries (e.g. the length of the corrupted data might be measured by timing the behavior of the receiver). Repeating observation of the behavior of the receiver for different alterations of the ciphertext can conceivably leak more and more information on the plaintext, similar to some padding oracle attack. Feasibility depends a lot on details of the compression and of the receiver setup. Fortunately, authenticated encryption (after compression and before decompression) prevents such attacks, and is now widely available, including in modern ciphersuites of OpenPGP/GPG.
Also, compression and decompression algorithms are almost never designed to be constant-time, much less to resist other side-channel or fault attacks, and there could be some information leak. However that's true for most data-processing algorithms in common use, so this concern is general when sensitive data is manipulated, rather than specific to using compression.