It's also missing some that have not had certs issued, but that are in public DNS
I don't want internally used subdomains to be public. Because of certificate transparency, the only way to achieve that is via wildcard certs.
Let's encrypt only supports cumbersome validation methods for those. Like changing DNS records every time you need to renew the cert.
Pretty annoying.
If you have unmanaged devices this becomes even more painful.
"Oh, hi, welcome to the company, please install this Root CA onto your machine to access <internal service>"
Because you can't scope CAs to specific domains, this causes everyone with any idea about security to start being concerned.
HSTS is about remembering to do an http:// -> https:// redirect. It's not about remembering a cert.
The downside of TOFU in browsers, is that it trains users to always click through cert warnings. Train them to do it once, and they'll click through it again when there's a real attack. The warning is the same on the first time visiting the site and on a later time visiting it if the cert has changed.
The TOFU UX in SSH is better, because it displays a different warning for when SSHing to a site for the first time vs SSHing to a site again and the cert has changed.
Some of those reasons are absolutely hilarious. I needed to set up an internal CA back in 2015, and wanted to limit the blast radius in case the private key was leaked. (Usually a "when", not "if" scenario.) I learned about the nameConstraints field and tried to use it. OpenSSL would ignore the key in a CSR input file. Okay, fine, the spec has an OID for the field so I reached for the nearest ASN.1 library to construct a modified CSR with the field in place.
OpenSSL broke trying to parse the file. Go's implementation blew up with a magnificent trace. I gave up and the internal CA was generated with a global validity scope.
I later learned that apparently Microsoft's PKI libraries had support for scope limits, but the feature was not used in real life. Likely because if such a thing came into contact with anything else in the wild, the underlying libraries would just implode.
If you had a self-signed client cert with a nameConstraints in the supplied CA chain, you could probably still crash a non-trivial fraction of web servers.
OpenSSL by default ignores many (/all?) extensions for security. You can still manually add the nameConstraints when signing the CA cert.
Sometimes it's not an option. I spent too many hours trying to figure out why some Android apps didn't want to talk with a service I self-hosted. They just ignored my Root CA cert installed on the phone.
As this (I expect) heavily uses cert transparency in the background, I want to point out another use case for that service. You can search the CT logs with wildcards to find your domain "neighbors" on other TLDs: https://crt.sh/?Identity=google.%25&match=ILIKE This usually gives you somewhat more active websites compared to just checking whether you can register the domain and somewhat weeds out squatted domains. I found that for our company one TLD contained a NSFW games store that way.
They've done simple reverse DNS lookups on our public IP range and indexed all those hostnames.
Certificate transparency logs have found names used for externally hosted websites.
There are some pretty old hostnames which haven't been used for 5 years or more, and were probably found with reverse DNS at the time.