Putting certs in DNS with DNSSEC authenticating them might be a more robust design overall, and would eliminate a lot of what is bad about HTTPS-everywhere (namely that LE trusts DNS to begin with, so doesn't add much to the web of trust, and that certificate issuance would be much more straightforward and automated from your TLD).
Unfortunately I have to disagree with you about the end of HTTP. ISPs have historically proven that they can't be trusted (NXDOMAIN interception, ad replacement/injection, DPI) and so for a non-negligable fraction of the world HTTPS (and DNSSEC or similar, although not enough people realize it yet) are a necessity.
I don't see alternative options except perhaps onion routing everywhere, but that only moves the goalposts to exit nodes without HTTPS and a PKI.
Another possibility for securing the existing PKI is to extend support for Name Constraints so that root CAs are only given authority to issue for subsets of domains, and finally making TLS only trust the most specific root CA for a given domain, e.g. if a TLS implementation has a trusted root CA with a Name Constraint of .example.com then it should not accept a certificate chain for anything under example.com from another root CA, and vice versa that root CA could not sign certificates for domains not under example.com. This would allow sites with high security needs to get their own CAs accepted by browsers, and allow breaking root CAs up by TLD which would match DNSSEC.
