Under a CT model*, if a CA alone is compromised, the attacker will need to write the misissued certificate to at least 2 publicly trusted logs in order to convince John that the certificate is legitimate.
Here any interested party (in particular the site-owner) can monitor the logs and take appropriate action with the CA if they detect a misissued certificate. This differs from today, where in the event of a CA compromise, neither the site-owner nor other parties are able to detect misissuance.
If the attacker also deeply compromises at least 2 publicly trusted CT logs (in addition to the CA) and is able to temporarily present split-views to the client, then this is where gossip of STHes and/or SCTs comes into play, the exact details of which are still be worked out, the latest draft can be found here:
https://tools.ietf.org/html/draft-linus-trans-gossip-ct-02.
The key goal of CT isn't to directly prevent a MITM attack (since compromising a CA alone will produce a cert that an attacker can send to logs to get SCTs), but rather to deter them by making such attacks easily detectable. To do so CT brings transparency to the operations of both CAs and logs such that any party can verify the correct operation of these trusted parties. In doing so we move the internet forward from the existing "trust" model to a "trust, but verify".
* For this we assume the browser requires at least 2 SCTs be present for all certificates, similar to Chrome's current policy for EV certificates.