There are several factors that come into play. The first is that encryption should hide patterns: if you have a file that contains the same content repeated several times over, encryption should hide this fact. If you have a weak encryption scheme, that leaks some information about patterns in the plaintext in its ciphertexts, then compression can help reduce the amount of information that leaks through. At least, that'st the classical theory. Any encryption scheme that's good enough to be used nowadays should take care of patterns all by iself though, compression or no compression (related tip: never use ECB mode directly). So the classical argument for compression before encryption is no longer that relevant (and compression after encryption is pointless in just about every case).
Another "classical" argument is that the chances of breaking a cipher increase with the amount of ciphertext you have to work with. So if you compress your messages before sending, you give an attacker less material to work with. Again, for any cipher secure under modern notions you should not have to worry about this. You should update your algorithms and key sizes every now and then according to the latest recommendations, rotate keys etc. - but the impact of compression on this will be minimal. Also if you encrypt each message under a per-message key and then transport this key bey encrypting it under a key-encrypting-key, which is a pretty standard thing to do (especially when public-key crypto is involved), you're controlling how much ciphertext gets sent out under any one key far better than you could by fiddling with compression.
The next point is that you might want encryption to hide the length of your ciphertext to some extent too. It's not too hard to gain some "metadata" about what someone is doing on a TLS connection by observing packet lengths and frequencies. Compression before encryption can help reduce the strength of the "signal" in some cases, but if you're worried about traffic analysis then you probably should be doing other things like padding to a fixed length - again, compression can make a bad situation a bit less bad, but it's not going to turn a bad situation into a good one.
Finally, you may have heard that compression within the TLS protocol will be abolished and banned in v1.3, or at least that was the case when I last read the draft. This is not to do with compression in general but because the specific way encryption, padding, MACs and compression interacted in TLS 1.2 and earlier standards had some vulnerabilities (CRIME, BEAST etc.). That doesn't mean that you can't compress at a higher (application) level or that compression weakens encryption in general, just that it has no place in the actual encryption module, at least not in the way it's done in TLS at the moment.
In response to comments asking further questions, here are two examples of how compression can help or hurt you.
Example 1 You're applying for a job and you agree to send your best friend an encrypted message telling you if you got it or not. Because you work in IT, a plain "yes" or "no" will not do - it has to be an animated GIF, so you prepare two files yes.gif and no.gif, and because you're worried about someone just looking at the filesize of your ciphertext you make them both exactly 64KB. But the yes.gif is full of colours and ponies and rainbows and when compressed, 60KB large - the no.gif is a more demure slow black/white animation and compresses down to 4KB. Your encryption program automatically applies compression before encryption.
In this case, compression ruins your security completely.
You've given up on the animated GIFs and agree that next time you want to meet your friend, you'll give him an encrypted e-mail simply saying "Let's meet next [day of week]." Your encryption program encrypts in 8-character (64 bit) blocks. If your message is "Let's meet next Monday." it fits nicely into 3 blocks, if it's "Let's meet next Wednesday." that's 4 blocks. Failed again. In this case, "mentally compressing" all days into their first three letters ("Let's meet next WED.") would have saved you.
In summary - compression does not generically help or harm encryption; if you typically have to deal with messages of similar lengths but varying levels of entropy/compressability then it might well do more harm than good.
The CRIME attack works because of a set of very specific circumstances that involve compression as one ingredient, but should not be applicable to file storage.