Take metadata. Because of how email works, it's effectively impossible to hide the To, From, and Date (or more accurately, the Received) headers. If you're worried about three-letter agencies, that's the only metadata they need, so you're screwed before you started. Theoretically, S/MIME allows you to encrypt additional headers (including the venerable Subject header), and has done so for 15 years, but I'm unaware of any email client that actually supports this feature, and the downgrade mode is pretty UX-hostile.

Another very challenging problem is that the flow of email pretty much destroys any chance of using a good secure cryptosystem. The email sender is not necessarily able to establish a direct, synchronous contact with the email recipient, even on a server basis. That makes protocol negotiation and perfect forward secrecy difficult. Not to mention that users generally expect to be able to open up email clients on unknown machines (especially webmail clients), which means practical key distribution tends to amount to "give your provider your keys," at which point the security advantage over the current state of all-connections-are-wrapped-in-TLS is negligible.

There's also the point that email's main advantage as a messaging system is its universality. But any new protocol is going to suffer from being supported in a small section of clients at first. If you can't get major email clients on board--and that includes webmail clients--then the universality of email is no longer an advantage in your proposed protocol. And if you're going to have to use a different client already, why bother with doing all the crap you have to deal with email syntax, MIME, SMTP, and IMAP?

About the only use case I can reasonably see for encrypting emails is in workflows like Bugzilla's "secure email" feature: the system is already relying on email for communication, there is a clear way to handle the recipient's key and protocol negotiation, and the metadata is irrelevant to secure.