BREACH and CRIME don't compromise sites, because they are attacks on clients, not on servers. The server is still involved in that, for instance, TLS compression won't be used unless the server agrees; so that, even if the CRIME attack targets the client, the server can refuse to use compression and this indirectly protects vulnerable clients.
Both attacks relate to the same general principle: encryption hides data contents, but not data size. Compression makes data size dependent on data contents. Therefore, compression can leak information on data contents that encryption won't protect. If the attacker is in a position where he can inject some data of his own along with the data that he tries to recover (formally, a chosen-plaintext attack), then he wins.
BREACH is another application of the concept, this time on HTTP-level compression. HTTP-level compression is performed only on request bodies, not on the HTTP headers, so BREACH is harder to pull off (while CRIME worked whenever a cookie was involved, BREACH requires the site contents to be amenable in some way to the attack). Disabling TLS compression will do nothing for or against BREACH.
Anyway, compression (be it for TLS or only for HTTP request/response bodies) will be applied by any machine only if it is reasonably sure that the machine at the other end of the connection will understand it -- because of some prior indication to that effect (in the TLS
ClientHello message for TLS, in a request header for HTTP). There will be no compression, hence no attack, unless both client and server support it and agree to use it. This is how mitigation for attacks on clients can be applied on the server.