Certificate Transparency (especially if mandatory) guarantees detection after the fact (if we assume the domain owner is properly monitoring known logs). It also adds a certain chilling effect that will probably cause attackers to look for other methods of compromising the target rather than risk sacrificing one of the CAs under the attacker's control (which, arguably, is what intelligence agencies are already doing as many high-profile sites have deployed HPKP).

It's not a real-time protection mechanism for targeted attacks and such - the mis-issuance event won't be noticed immediately, and revocation is both slow and, well, broken in general.

The existence of HPKP is still a good thing for the Gmail's of this world, but I agree that mandatory CT is probably good enough for 99 out of 100 sites out there.

I can imagine extensions to CT that would make it better at combating real-time attacks before they can affect anyone.

For instance, suppose a new certificate didn't become valid for a certain amount of time after the publication of the corresponding CT log, to give the domain owner (or rather, automated processing working on their behalf) time to shoot it down somehow? You could choose how much of a delay you wanted, trading off between security and potential downtime (if you lose all access to your existing certificates, can't revoke them, and have to issue entirely new ones).

If you use any non-automated CA, you should know when renewing your certificates, so you could open up a window to renew; in the absence of that, a fully automated process could notice a new certificate for your domain and automatically shoot it down.

If you use an automated CA, you (or the automated process) should similarly know the window of time you will renew in, though in that case someone could learn that and take advantage of that window. On the other hand, given sufficient confidence in the automated CA you could use CAA with it.