I disagree with some of your points, but also want to note that what I gave as email's weaknesses are frequently also strengths. I'll try to clarify the distinction.
1. Clients: There are cases in which functions which ought be standardised aren't. These are particularly problematic where archives of email from multiple systems are presented. References, quoting, and reply styles are three long-standing friction points. Various conventions for noting changes in documents -- GUI client users relying on word colour won't play well with those using text-oriented platforms. Including now a great many mobile email clients, not just mutt and pine users.
Standardisation is what makes more complex interactions possible, whether you're talking messaging formats, file formats, or nuts and bolts sizing. This makes for an interesting though likely side conversation. My point is that the lack of agreement across major families of email clients makes more complex email interactions quite painful, something I've noted for decades.
The biggest problem I'm seeing is that client tool vendors simply aren't addressing numerous areas of concern, such as those I've listed here, or working in the least toward interoperability. This is for quite understandable reasons (gaming and abusing standards for selfish gain is an old trick), but it doesn't make the resulting situation any more desirable.
2. PGP/GPG doesn't address metadata privacy at all. It's not supported by many clients (see above), and has posed very long-standing issues by way of key management and web-of-trust issues. Moxie Marlinspike is among the voices suggesting PGP may have to be swapped for something else. I'm not sure I agree with his assessment, but his isn't a voice to be trifled with.
Without encryption at the transport layer, and on a guaranteed basis, privacy protections simply don't exist. The level of concentration of email services leads to other massive concerns. Much of that is due to a lack of sufficient trust mechanisms built in at the peering level, so one problem (spam + trust) feeds another (privacy).
3. The issues of user idiosyncracies is amplified by other factors, including the client issues above. Tools to standardise formats, or convert to/from various standards, might help. My primary issue is that problems in one area of the messaging world amplify those in others. It's a mess, and neither users nor tools are helping much.
I'm aware that people aren't robots. Not all of them, at least. Providing tools that make it harder to do the wrong thing would help considerably. That's not what we have now.
4. File formats: again, it's a matter of standards. Negotiation of what is/isn't permitted, and/or required, on a given conversation, for example, might go a long ways to addressing this.
More generally, email as with the Web operates as an error condition: http://deirdre.net/programming-sucks-why-i-quit/
5. The directory. Addressed elsewhere. More a characteristic / non-characteristic of email as a whole, though one many proposed replacements get on the wrong side of (trying to provide a total global directory).
6. Ties in to clients, security, authentication, privacy, and a mess of other factors. It's a problem, but it's a problem grounded in virtually every other part of the email system.
7. Reputation: see above. Though I agree that it's not something that can be addressed through a central agency. Another much longer discussion.
Again: the point in my list is to note where email fails most egregiously. I like email. I've used it for thirty years. I've defended it, strongly, against numerous previous criticisms. But I've come to change my mind, in that several of the fundamental premises and capabilities of it are now fatally flawed. It needs a massive refresh.
(I'm also a fan of IRC.)
1. Clients (and some servers) mangle email. This isn't a complaint about email; it's a complaint about bad software in general. It's also not my problem; I don't use such clients or servers and it's up people who use them to work around these flaws.
2. Privacy. Real privacy is achievable via email with PGP; everything else is no different than literally any other form of communication. Privacy will always be between Alice and Bob. The transport layer is just a transport layer. With email, those who want it know where to get it. Sure, it's not simple, but if it were simple it would not work. With other solutions, it's frequently not even almost an option. I don't get to audit Whatsapp's server logs; who knows what agencies have access.
3. Users. All systems of communication rely on compliance by users. Just about none of your thoughts on this topic are specific to email. There is no 'go fmt' for human expression, and whenever someone tries, human expression is no longer present. Always speak to your audience, even in an email. It's up to you to decide if a given audience is important enough to acculturate to their norms.
4. File formats. You can send anything -- thank god.
5. The directory. This has no place in the layer. It's like complaining that they didn't build the concept of a web sitemap into TCP/IP. Twitter, Facebook, and HN are one-to-many communications platforms, some of which have hacky ex-post-facto one-to-one mechanisms. Email has been n-to-n from day one. Pretending that it is universally desirable to map addresses to individuals and vice versa is incredibly naive. I not only have several email addresses for different roles, but I have several phone numbers and several postal addresses for different roles. On twitter, facebook, and HN, I would have to jump through hoops to achieve this, and on some services it's even against the TOS. This lack of outside force regarding how I handle email messages is its greatest strength -- I can trivially set up a mailing list, which is nigh impossible on, for instance, twitter, and utterly impossible on hacker news.
6. Spam and spoofing. Absolutely a problem. Will remain a problem until solutions get specific buy-in from multiple interested parties -- and that last part makes all the difference. Each time some SV megacorp institutes a real-name policy, or a captcha, or or or... another class of users is sidelined, disenfranchised, or otherwise excluded from the communications process. Email does not have that, because there are standards to adhere to, and some random project manager does not (quite yet) have the power to shove new standards down our throats. Thank God.
7. Reputation. This is now and will continue to be the universal problem across all of the internet. Solving this problem by trusting a third party service provider to do all of your vetting for you will fail, because all they do is push that problem downhill to the users. Joe Random wants to be friends on Facebook. Now I have to do casework to decide if I want Joe to access my inbox, and if Joe is even Joe. Susan User would like to add me to her professional network on LinkedIn. Same problem. The only difference is that when I run an email server I maintain agency to manage the entire scope of these decisions, instead of trusting that Facebook or LinkedIn is reasonably sure that Joe might actually be Joe, or that Susan is not in fact a ten-year-old Martian girl mining my profile for password recovery answers.
Is email perfect? No, of course not. But it and IRC are the closest things we have to level playing fields for someone willing to do the work to take their place as a first-class citizen of the internet. They will only ever be replaced by standards; no proprietary product will ever unseat them.
Mail clients written in the eighties can still work today. Mail stores created then are still readable by today's clients. The protocols and processes involved have definitely changed, but they've _evolved_, rather than getting thrown in the trash and replaced with version 2.0, then 3.0, etc, ad infinitum, ad nauseam.
Given the choice between an evolving collaboration and reliance upon the goodwill of some stranger I can't even name, my choice will always be the former.