[0] https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...
With Let's Encrypt we made a lot of people's certificate management a "fire and forget" thing, which is exactly what we hoped to do, but if they completely forget about it, it may be that there will be lots of targets against whom nobody would notice certificate misissuance.
(I wasn't aware of your credentials when I made my previous comment so I assumed you didn't know about mandatory certificate transparency which is a mistake on my part, sorry! I'll make sure to check profile about sections before I assume again.)
Indeed, the fact that Cloudflare emails out CT warnings due to their own backup certs is rather embarrassing.
Also, we made Certbot randomize the subject key by default every time it renews, so you have a huge amount of churn in subject keys, so you can't just say "oh, well, this public key has been used for a long time, so it's probably correct!". Every subject key is typically new and is unrelated to every previous subject key.
I hope that won't turn out to have been a poor trade-off. (We thought it was good to have more turnover of keys in order to reduce the impact of successfully stealing or cryptographically attacking one.)
Another example: Yandex Browser ONLY trust Russian NUC certs if they are in public CT logs,not otherwise (https://habr.com/ru/companies/yandex/articles/667300/ - text is in Russian) (as far as I understood, NOT trusting this CA al all is not option for them or their users, and if user is using chrome/firefox and needs access to sites which use this CA - CA will be just be installed manually so Yandex's solution is more secure, thanks to CTs).
Intel people really don't want to get caught (and whatever CA they use really does not want to get caught), CT turns the attack into a gamble. Even if nobody is checking most sites, CT still creates a deterence factor. Not perfect, but a lot better than the previous status quo.
It's also why I'm personally against SMIME and think it's a bad idea.
