These are "limitations" according to the author. But IMO they're the reason I like email:
- I like to be able to reply when I want, without the sender having the expectation of everything happening in real time, I have other things to do than answering real time to everything.
- Anything is hard to manage in huge amounts, which is why we hide less important stuff. Email has folders where you can put stuff in. You can archive emails. Or maybe this management issue is technical, as in "storing petabytes of emails is a difficult task" ? In that case, I have no real answer.
- I actually like the concept of mailing lists: they work where I already am (ie my mailbox) and I can stay up to date just like in a forum. And person-to-person dialogs do indeed work very well with email. I don't see that as a limitation.
Also, about this:
"Stream is a group of threads. Simple as that."
That does not sound simple. In fact, just from that sentence, I didn't understand at all what it meant. I had to read on to get the idea. But I do see the point of "streams", and I agree that filters are usually complex to setup and maintain.
The part that I don't understand is this one:
"With proper user/access management Streams could replace not just email, chats and group chats but also forums, blogs, mail lists, RSS and most of web 2.0 communities."
It sounds like what you need is RSS everywhere. RSS has a pull model too. You can setup ACLs on an RSS feed if you have some kind of authentication in place. It can replace mail lists, except that you'd still need to be able to push messages to it, which I don't see anything about in the blog post.
Finally, regarding this:
"This fixes ambiguity around do-not-reply@ addresses"
I get the point of ambiguity and I have replied to no-reply addresses before myself, with an error message coming back. But I think ambiguity could be fixed with a header here, instead of throwing away the whole email infrastructure.
Imagine a "X-No-Reply: true" header. That way, email clients could disallow replying to such an email address. This has the advantage of being backwards compatible with everything that exists.
Overall, I do think that you can try something new, trying to "replace" email. But realistically, Google has tried several times and is struggling. Email has solid tooling and knowledge built around it, and I think trying to push for its self-improvement is worth a look.
Slack is sometimes said to be an "email-killer", but the fact is it replaces only one use of email. At my last company, we used Slack for real time stuff, notifications, quick questions, but not for everything. And that's great. Because email sucks for real time stuff right now (although initiatives like JMAP may make things better).
Email seems to carry the notion of importance, which is not true of chat messages I think. The reasoning behind this is, I think, an incoming email stands alone, whereas a chat message is quickly surrounded by other messages.
Also, emails have a clear receiver, the receiving email address. This means that if you get a message to "email@example.com" and you are a dev, you are de-facto concerned by this email, which is a reason to read it thouroughly. This is not true of chat messages which do not have a "receiver" but are instead posted to the more liberal notion of "channel".
This is critical. Understandably, "chat" user interfaces don't make individual messages stand out by themselves. This means that it is easy to miss a message, or even a conversation. It also means that you can't delete everything but the important stuff you need to reply to, which is trivial in email clients.