I think part of the problem is that the one public CA tree is used for many different purposes. Validating the host name for HTTP is one goal. Identifying trustworthy companies is another. The VeriSign certificates are expensive because the identification is hard. Even then, it isn't as good as it should be. On the other hand, for many purposes just verifying that the DNS hasn't been spoofed is good enough. Certificates based on the DNS would be much cheaper. There already is a hierarchy that the CA tree could follow.

For example, I once worked with a credit card processing system that used SSL to protect the transactions. That is a good thing because SSL is a very well designed protocol. The problem is that the server's certificate was signed by VeriSign. The client's used a CA file that listed the VeriSign CA. The problem with this is that any CA in the VeriSign tree could impersonate the server. This may be an acceptable risk for the shopping site, but it a big danger with the credit card processor that sits behind it.

What they should have done is signed the server certificate with by a custom CA. That CA would be the only one configured for clients. Clients should also get client certificates signed by the only CA that the servers trust. The trust is limited to the organization that runs the servers and issues the certificates.

Simarly, organizations shouldn't use the public CA tree for internal authentication like with email. It requires more work to distribute the CA certificate to all the clients but it is more secure because the trust doesn't include all the public CAs. On the other hand, since browser don't separate trust domains for certificates, the private CA could be used to spoof any web sites.