I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.
One way this is true is that people won't use security if it isn't usable or easy to use. For almost two decades we had CA workflows that sucked. Certificate use has spiked in the last couple of years. Why? Witness the outstanding work by LetsEncrypt which is now allowing Chrome to flag insecure login forms.
Other examples; DDoS defense as a service, facial recognition that unlocks your phone every time you pick it up, cars that lock when driving, and fobs that make passwords almost irrelevant.
Good security and making someone's job easier are one and the same.
Even the "corporate policies" is a security thing, not "making someone's job easier". Presumably Facebook handles their certificates carefully: if any engineer could obtain certificates the odds that they would and that the certificates would be passed around in email attachments is 100%.
As browsers are unwilling to validate DNSSEC directly it would allow browsers to just check the certificate. This could be complemented with a relevant HTTP header that forces the browser to only accept the certificate if it has been given out to DNSSEC validated host.
Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.
Chrome enforces this for all new certs since earlier this year.
Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.
Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.
SCTs get to the browser in one of three ways:
1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.
2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.
3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.
There are better ways to handle it, I think, but they may involve changing how we both sign and verify certs.