Can we get rid of CAs with CT?
EDIT IN LIGHT OF COMMENTS:
It sounds like the question you are trying to ask is:
I don't like the all-eggs-in-one-basket nature of CAs, so can we design a new TLS system where each cert needs to be signed by multiple CAs? Can we use CT for this?
Yes, you could design such a system so that multiple CAs would have to work together to issue a fake cert, this raising the bar. It wouldn't change the fundamental nature of needing CAs and needing to trust them, but at least you wouldn't have to trust them individually.
Current TLS implementations can't do this because an X.509 certificate object only has a single CA signature field. Current CT implementations are also not designed for this because CT logs are meant to monitor CAs to make sure they are doing their jobs properly, not to themselves be CAs.
So yes, it's possible to get Let's Encrypt-like functionality with a system like this, but would not be compatible with current technologies. CAs are not ideal, but (for now at least) the world seems happy enough with putting them under a lot of public scrutiny and pulling them from browsers if Google or Mozilla catches them doing something they are not supposed to be.
There are, however, a few trickier points about TLS certificates that I think would be hard to handle:
Revocation
One of the core features of PKI is the ability to contact the CA that issued your certificate and ask them to revoke your certificate. This may be because you had a security breach (hack) and your private key might have been stolen. It might be because you are decommissioning your server and you won't need the cert anymore. Whatever the reason, you want the next time that a browser tries to validate your cert, for the CA to return "NO! Cert Revoked!".
CT logs currently don't track this (it's the job of the CA / OCSP responder). If you went to a multi-CA model, then I guess revoking it on any one CA would do (but then we're back to a single point of failure model where one rogue admin could cause a DOS) so this would need very careful thought.
OV / EV certs
From your question, I take it you only have experience with Domain Validated (DV) certs, these are the ones that Let's Encrypt offers where ownership can be verified by automation. There are two other categories - Organizational Validation and Extended Validation where humans at the CA do extensive record checking, phone calls, and potentially face-to-face meetings before issuing them a cert because with those levels it's not just the website that's being validated, but the entire company that owns it. That's where you see a green bar with the company name embedded in it:
OV / EV certs are expensive (several hundred to several thousand dollars per year) but, I assure you, many companies buy them because of the extra assurance. This would be very hard to accomplish in any non-CA PKI model.
PREVIOUS ANSWER
There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.
Fine, but do you have an alternative? CT only? So what's stopping me from CT logging a self-signed cert for google.com and being able to MitM Google?
From your comment:
we could guarantee that only the domain owner can write to a CT log
... so I need to submit a proof that I own the domain, and the CT log server needs to verify this proof before adding it to the CT log? But what if the CT log admins are not trustworthy and slip in one that didn't actually pass the verification? You've just invented CAs again, but now the CA and the person who watches the CA to keep them honest (CT logs) are the same person.
Trustworthy or not, CAs are a necessary part of the PKI system.
CT in no way actually replaces the original function of a CA; it just makes it traceable and public.
CA's also have a function to play out in distributing and delegating trust that is not covered by ACME or CT (directly).
The main issues with CA's are that they are costly (or too costly) and that in the past some did not do their work as expected/required — namely, to verify, authorize, and authenticate certification requests and issue certificates to people other than domain owners. CT solves this in part by at least having a traceable source of who created what certificate, and together with their private logs we can retrieve who did said request.
Your proposed solution does not eliminate the risk that is currently there (and as such is not better), namely that of someone impersonating a domain owner and requesting certificates for a domain that is not under their control.
All current replacements for CAs' task of delegating trust (like the web-of-trust) are limited by the bootstrap effect (a.k.a. the chicken-or-the-egg effect) in that you need a larger group of already trusted sites / users to use it.
For returning control to domain controllers and giving them the tools to say what certificates are valid, we have the DANE initiative. This is however highly dependent on DNSSEC, and that is also not widespread enough to make DANE viable as a replacement.
So currently we have no other way to delegate trust than by using CA's to do that job for all of us until the other technologies mature enough and are in use enough to finally replace the CA's.