Most users will only use encrypted/signed email if encryption and signing is done automatically. If the automatic encryption/decryption/signing/verification is done by the server (e.g. GMail), security gurus will complain that it isn't secure enough.
If the encryption/decryption is done in the "totally secure" way on the client, users complain that they are locked out of their email too often (can't access it from a secondary location and/or lost their keys).
Average users don't have an effective method for exchanging keys.
Email security doesn't really work without a signing mechanism that results in nonrepudiation. But, a lot of users don't want nonrepudiation for the messages they send; they want nonrepudiation for the messages they receive and 100% repudiation for the messages they send. To implement that, you need some kind of expiring signing keys, separate from the encryption keys, which S/MIME and GPG UAs don't natively support.
Consumer-level email services are mostly webmail at this point. There is no good solution for securing webmail beyond TLS encryption between SMTP endpoints (e.g. between Google, Hotmail, and Yahoo, and between the browser and the server). However, your email is still just a subpoena away at every endpoint.
Server-side spam filtering doesn't work with encryption. As soon as spammers start using your encryption key, the spam will pass right through the filters. That means you need to keep your encryption key private. But, that makes key exchange and revocation checks even more difficult.
Online certificate revocation checks are important for email security. However, the process of doing the revocation check leaks sensitive information (who you are corresponding with) if it is optimized for performance. The current means of revocation checking that is optimized for privacy has unworkable performance issues. A new, nonstandard, mechanism for doing revocation checks is needed. But, everybody hates anything proprietery, so it would have to be standardized, but the standardization process will take years.
Everything related to internet email has been free/open source/public domain since the beginning. Any solution that someone comes up with will have to be opened up and freely given away--including the specifications and reference implementations--before it has any chance of being adopted. This limits revenues. Yet, you need a costly infrastructure to implement the service levels that users expect from email (99.9% uptime and high performance and pennies a day or free).
I have been working on a solution to most of these problems but I don't have the resources to move it forward. Please email me (brian@briansmith.org) if you are serious about coming up with improvements to everyday email security so that we can compare notes.