PKI in a nutshell: the CA signs your CSR which was created with your private key; the CA gives you a cert based on your CSR; you show random people a website using your private key + CA-signed cert; random person's browser trusts your private key+CA-signed cert content because their browser trusts the CA-signed stuff implicitly.
Why we need more than 1 of them: in case one of them goes down and so we can't get new certs; in case one gets compromised and the browser revokes their trusted CA cert; diversity of "features".
What could we do instead of this process?
Idea 1: the registry becomes the CA.
Why?
To get a cert, you have to prove you are allowed to have it. Currently that almost always involves proving that you currently control the IP space that is pointed to by a DNS record. There are other verification methods which are somewhat more problematic than this, but this is the simplest method. And if you can find one single CA which will create you a cert if you can do this, that means that if anyone can do it, they can get a cert. Meaning that this verification method is the minimum security barrier for getting a valid cert.
How can an attacker to subvert this process to generate a valid cert for any domain?
Options: 1) Take over the domain, by hacking the domain's account at the registrar. 2) MITM the registrar, such that updates to the registry's NS end up controlled by the attacker. 3) Take over the domain, by hacking one of the domain's nameservers. 4) Perform a DNS hijack, such as cache poisoning, so when the CA looks up your domain to find the IP space, you return attacker IP space. 5) Perform a BGP hijack so when the CA tries to connect to the IP space, it connects to attacker-controlled IP space. 6) Plenty of others based on other validation methods such as DNS record alone, HTTP [no S] content, a pre-configured list of e-mails for a domain, etc.
How to prevent all but one of these attacks?
Option A: Make the registrar the CA. The registrar would simply request the user use an HTTPS API to request a new cert, using an API token generated by the login for the domain's account. The only way for an attacker to generate a cert at that point is to either hack the registrar account, or hack the customer's server to get the API token (basically the same impact as if they compromised the customer's web server).
The browsers would trust the registrars who would follow the exact same stringent guidelines that CAs use today. The difference to the end-user is the CA is run by the registrar.
Option B: The registrar and the CAs stay independent, but they use a standard secure protocol to authorize signing of certs using a customer API token. Same benefits, but an extra hop. Browsers continue working as before, users use an HTTPS API to the CA to generate the certs.
With either options A or B, there's no more stupid hoops to jump through just to prove you own the domain and thus deserve a certificate.