- connection security: are the crypto credentials being used for signing e-mails or encrypting web traffic belonging to the entity in question? This should have been solved by putting the fingerprints into DNS so that clients can validate it on their own instead of having to trust a CA. DNSSEC and certificate pinning would have been the answer, but both are incredibly complex to set up and littered with failure scenarios that may be very difficult to recover from, but in the end it got "solved" by LetsEncrypt/ACME where the CA acts as a proxy. For e-mail, it got solved better by DKIM, but that's only applicable to the scenario "an email server wishes to check if an email it received from example.com actually originates from example.com", but not for "an email client wishes to send an encrypted email to foo@example.com and needs the public key for this mailbox".
- connection authenticity: is the server a client is talking to (e.g. bank.com) actually belonging to the legal entity the user expects it to be? That one is what CAs were originally designed to verify and where a much larger amount of trust is placed on the CAs doing their job correctly. One idea to do that was SSL EV certificates, but for whatever reason these fell out of favor - and right now, there is no replacement at all for this use case.
Additionally, the situation is made even more complex by legal or compliance requirements, e.g. banks who have to record virtually everything their employees do. For that, they have to break HTTPS by providing their own root certificate.