I think that the answer to this question is a bit more involved than it first seems. The reason is that the compression attacks work when different lengths after compression reveal information about the plaintext. This is of course a huge problem. However, you have to ask the question without compression as well: when does the plaintext size leak information.
In practice, the plaintext size leaks information in many settings, and it's very problematic. A very nice paper that deals with this is called Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (it appears at IEEE S&P 2010).
So, this question arises when using compression and when not using compression in exactly the same way. If you have a lot of control over your application, then you can pad to a fixed length (if this is feasible regarding efficiency). This is indeed harder to do when using compression since you typically don't have a fixed useful upper-bound on the post-compression length. If you did have such an upper bound, then you could compress and then pad.
In many cases, the actual values being encrypted are not known ahead of time and the person designing that part of the application knows nothing about security. Then you are in trouble whether you are using compression or not.
In summary, length leakage is a real problem that is way too ignored. The use of compression in some cases makes it worse (like in the CRIME and BREACH scenario), and in some cases it's the same problem as without compression. It depends on the application and you have to do the analysis.
(Just to answer the specific question: if you are saving 42% by using compression, try to estimate the maximum foreseeable size after compression and pad to that; you may very well still save 25-35%.)