I'm continually amazed at how insecure almost every aspect of internet routing is - it mostly boils down to a sort of "gentlemen's agreement" that everybody will follow the rules.
Basic security mechanisms when it comes to large ISP networks are a pipe dream though, instead we get vendors pushing extremely vulnerable Juniper gear cause its reasonably priced, meanwhile these boxes have new root exploits found multiple times a year. None of the vendors give a crap about security, Cisco pays it some lip service (to win gov't contracts) but charges a premium for basic features.
Today you'd do better, with hindsight being 20/20.
CAs aren't mandated to log certificates for you (and indeed some offer the possibility to deliberately not do so for reasons I'll get to in a minute) but if you run a mass-market CA logging certs by default is the only possible way to remain in business since otherwise your entire customer service budget will be spent explaining to customers how to log the certificates and make them work with Chrome.
Firefox and Safari have announced plans to require SCTs but without a specific version or timestamp deadline. Apple's language says "calendar year 2018" but that's probably ambitious. It scarcely matters, Chrome is already too many users for a commercial CA to ignore.
So, why aren't all CAs logging every certificate and baking the SCTs into the final certificate? Well, when a certificate is logged that makes it public, but power users may want the ability to sidestep that. For private systems they may just have decided to never run Chrome (and good luck to them in the future when IE6 on Windows XP is the only option left that doesn't check CT). But for public systems if you're technically capable you can get yourself unlogged certificates, then at launch time log them, collect the SCTs and deliver those to the TLS client rather than baking them into the certificate. Google does this, a few branding practitioners do it. It's very important to get it exactly right because if you screw up your certificates are worthless until you fix it. But if protecting naming is important to your business it's an option.
Under current policy this "nothing" means Google plus at least one independent log operator claim to have seen it and logged it. This eliminates the scenario in which a powerful adversary obtains certificates but only shows them to a single victim or small victim group. Whatever they did, everybody will see it.
But sure, it won't happen overnight.. just saying gaps are closing :)
Try this URL: https://invalid-expected-sct.badssl.com/
If you visit that in Chrome it gives you a full page interstitial warning it's bogus and if you click past the page is labelled "Not Secure".
In other popular browsers it works fine, because it has a perfectly nice certificate but the Bad SSL site is deliberately not presenting the SCTs for it. [[ It's hard to do this by accident, most places that give lay folk a certificate will assume your goal is to have your certificate accepted, so they will log a "pre-certificate" for you and bake the SCTs inside the certificate they give you and you can't remove those ]]
But yes, fully completing Certificate Transparency will be more work, we need a Gossip system so that monitors can consult each other to detect a split horizon, and mechanisms for clients to show summaries of what they know to determine if there are conflicts.
What we have now is like if you have a house you've half-built, there is no roof over two rooms, and no electricity, and the floor is bare dirt. But, it's still a house, and in a rain storm it's better to be inside that unfinished house than out in the cold and wet. The people outside in the rain don't think "That guy's house doesn't have triple-glazed windows" they think "Lucky bastard isn't out in the rain like me".
And so begins the ever greater attacker regression.
https://www.nonog.net/wp-content/uploads/2017/06/Altibox-An-...
https://www.networkworld.com/article/3254575/lan-wan/what-is...
Sure, it's better than nothing but RPKI doesn't validate the entire path, only the origin.
If you want path validation, you need BGPSec. But BGPSec is basically un-deployable in real-world networks.
Your comment simultaneously contains almost no information is super off topic.