In order to attack an HTTPS connection, the attacker has to have MITM position against the victim: the ability to intercept TCP connections.
Such an attacker can obviously also block the CRL/OCSP lookup if one is made. Even with revocation checking enabled, no browser that I know of will fail a TLS handshake if the revocation check is blocked.
(You can configure Firefox to do this. Tools -> Options -> Advanced -> Encryption -> Validation, check the box for "When an OCSP server connection fails, treat the certificate as invalid" - so says https://wiki.mozilla.org/CA:OCSP-HardFail)
I claim that soft-fail revocation checking is basically nonsense. That's the point that I'm making in https://www.imperialviolet.org/2012/02/05/crlsets.html.
Making it hard-fail isn't viable: it makes OCSP servers a single point of failure for huge parts of the web. That's why Chrome has a CRLSet system that actually can achieve real goals. The attacker has to persistently MITM the client in order to block the CRLSet update.
The CRLSet is limited in size. I had hoped that CAs would use the reason code mechanism in CRLs to remove the "administrative" revocations that dominate their CRLs. (Those are revocations where there's no suggestion of compromise.) Some do, but most don't.
It's not true that the CRLSet doesn't include any Comodo or Symantec (who now own Verisign's old CA business) CRLs. In fact, Symantec/Verisign CRLs are the biggest contributor to the CRLSet.
But it's true that the CRLSet is limited in size. We focus on CRLs for CA and EV certificates. I don't think the world has a great answer to the revocation problem when certificates are valid longer and longer periods.