To address your concern, clients will have TLD certs in their trust store. TLDs issue intermediate CA certs to registrars. When you get a domain, they issue a cert (not x509 neccesarily) that allows you to issue certificates like an intermediate but restricted to that domain and its subdomains. So news.america and news. Under ycombinator.com will have separate certs,signed by the owner of ycombiator.com which on turn has to have their CA cert signed by a registrar.
This actually can improve security, because you can isolate your intermediate signig key from the rest of your services, and possibly have a dynamic process of issuing extremely short lived certs by your CA box to all of your services. Code signing certs,s/mime,client certs, eap-tls,etc... Can all be more easy to use. For example, if I could use eap-tls to connect to wifi at an airport or starbucks using a cert I issued myself under my domain (or under my work/school domain). Things that have been notoriously hard to adopt like TLS client certs could easier to use because anyone can have a client cert issued to them by any domain owner (likely the domain of their email provider for most) because any site can verify their client cert using this system and anyone with a domain can issue certs. This is the natural and most sensible way.
As for trust, you already trust them with the power to transfer your domain. If someone compromises your registrar account, what stops them from taking over the domain,pointing it at their own servers and getting a new cert from ISRG? Imagine getting a government ID and to verify it's legitimacy,people have to contact 3rd party companies instead of the government, that makes no sense. Things are the way they are because public key crypto was not used widely when DNS and the internet became a thing.
> let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain.
You should use Let's Encrypt's implementation of 3.2.2.4.7 which is the dns-01 challenge as I already mentioned. Or use another vendor's own implementation of 3.2.2.4.7 or any of the half a dozen or so non-web methods listed.
> Or let's say I need non-TLS x509 such as ipsec.
The Web PKI can't help you. Leaf certificates in the Web PKI contain an EKU 1.3.6.1.5.5.7.3.1 which says their purpose is TLS server authentication. There is no global public PKI for IPsec. Feel free to try to make your own, but I expect it will be an expensive and thankless task.
The central issue of a PKI is trust and domain name registrars are not on the whole very trustworthy. We're talking about the industry which invented Domain Front Running - the idea of waiting until a customer shows interest in a unique product (a domain name) and then buying it yourself so that they'll have to buy it from you at an inflated price.
I sympathise with the desire to build a parallel PKI baked into the DNS system, but the Web PKI is not that system and there's no practical way to mutate it into that system. If you believe DANE is the only way forward you should go help people make DANE work better, not argue against the Web PKI.
Issuing "a certificate" at time of domain registration greatly misses the point of Internet hierarchical naming by the way. While it would be technically possible for every domain to hold a single wildcard certificate and use flat naming (so news.america.ycombinator.com couldn't exist, it would need to be news-america.ycombinator.com) that's a terrible security choice. Necessarily where a service corresponds to one specific name the certificate and corresponding private key should be for that name only, and not a hierarchy of related names in order to mitigate risk.