Yea from a technical perspective I think it’s ridiculous that organisations like lets encrypt are even needed. DNS could easily service both roles and make letsencrypt redundant.

Here's how it could work: First, you generate a tls signing certificate. The signing cert gets stored in DNS. When anyone makes a DNS query, the response contains your root certificate's signature (HMAC). When you initiate a TLS connection, you check the root certificate in the cert chain against the signature provided over DNS.

The dns response would also need to be cryptographically signed by the dns provider. Instead of operating systems shipping trust roots of TLS cert providers, we ship the root certificates of DNS registrars. Eg, .com, .com.au, etc would each publish one or more root certificates that would get distributed with operating systems.

Trust already depends on dns (since that’s how you prove who you are to letsencrypt). So the whole system would rely on fewer trusted entities - which would hopefully make it more secure. It would be simpler to run - less organisations needing to do anything. And simpler to make use of, since you wouldn’t need programs like certbot to keep your tls certs up to date. This would also prevent the danger of malicious TLS providers being involved in MITM attacks on TLS.

I think we should have gone the legal route, forbidding JS injection in pasing HTML by carriers by e. g. conditioning their liability to the modification of data.

That is, if they inject JS or modify the data in any way, they are liable for the content, otherwise not.