The biggest reason for it is that in practice email isn't as open and decentralized as people like to think. For most of its history all advancements were controlled by Microsoft, AOL and Yahoo, and today it is controlled by Microsoft and Google.
Most of the OP list of things they don't like are about client UI presentation. Inherently unrelated to the protocol itself.
I don't have any of those issues because I use a client that does the interaction and presentation exactly how I like it.
Reformatting top-quoted replies. This is possible with email because you can pipe the messages through any preprocessing you want. Inserting custom processing into the delivery pipeline is generally impossible with all proprietary systems, but easy with an open standard like email.
HTML formatting: Again, easy due to customizable preprocessing and/or viewers.
Eighty people responding to a thread: This is threading, handled natively by most good email clients. Gmail makes a mess of it though, so I get why it'd be painful if you use gmail. Don't use gmail.
> because the protocol leaves so many decisions up to clients.
I feel like this is a misunderstanding. The clients have nothing to do with the protocol (SMTP), that's the job of the MTAs (mail transport agents).
The client provides the UI/UX interaction part. It is an immense strength of standards like email that there are tons of clients. You may want a completely different UX with your email than me, so you're free to have it exactly the way you want and so am I. And we can still message each other. This is impossible with proprietary walled gardens.
Email threading is trivial, nothing magical about it. Most every decent email client will properly thread conversations. Gmail will not, so yes gmail is super painful for long threads. Use a better client.
I agree with everything else and think "managing group messages" has other issues. For example, it's nice that I can duck out of an iMessage group, but can't duck out of a text message group or email chain.
no shared concept of a group/channel/...
no shared history support
no shared concept of a thread
no consistency about how previous replies are referred to (e.g. different quoting styles)
no real identity support
...
mailing lists
> no shared history support
Your own client or provider can store history. you also don't own someone else's history - a good feature imo.
> no consistency about how previous replies are referred to (e.g. different quoting styles)
A preference for individuals to decide.
> no real identity support
What's a "real" identity? my email address is my identity.
Not understood at the protocol level, not visible as such in the client.
> Your own client or provider can store history. you also don't own someone else's history - a good feature imo.
It's a nightmare in practice. Catching someone up on a conversation ends up being a mess of forwarding multiple overlapping but partially distinct emails and then constantly having to resend messages as different people get dropped in different replies. Exiting such a conversation is even harder.
> A preference for individuals to decide.
The cost is much bigger than the benefit.
> What's a "real" identity? my email address is my identity.
There's no authentication. You can't associate yourself with multiple organisations except by using multiple addresses, and then there's no way to reflect that those are somehow the same.
So I often have organizations that send email pointing to their proprietary webmail. The alternative is sneakernet, hard copies, or even faxing.
Also, wouldn't encryption fix this problem? I don't understand how it might be implemented in the real world, but if you encrypt with your private key, then their public key the message should be safe in transit, and at rest (unless they leave it decrypted on disk)
If that's all there is to it, then why do people use other solutions?
> Also, wouldn't encryption fix this problem?
Kind of. The problem is the protocol and lack of consensus prevents this from being feasibly implemented. Personally, I think encryption in transit is a low probability threat for me. I would also like certain data to "expire" or go into "cold storage" after a period of time. Sending it in a side-channel, like Dropbox or Google Drive means I can delete it or revoke access after a period of time but this breaks email.