Eleven nines is very excessive. Frankly even six nines would still feel excessive, though I’m sorry to say that five might not be any more. Fifteen years ago, I think even three nines would have been excessive. Legitimate outgoing SMTP was fairly common in those days, and botnet SMTP probably proportionally rarer. You know what, even one nine might have been excessive less than twenty years ago.

Sending mail directly from a residential network by connecting to the given mail domain is a nonstarter. Hasn't worked in twenty years or more. That doesn't require a MTA; only a MUA.

Your mail program (MUA) like Thunderbird or Outlook, or the mail utility in a Unix-like OS, can perfectly well work without a configured SMTP server. You send to bob@example.com. The mail program will do a MX type DNS query for example.com and find out that the mail.example.com is the mail host for that domain. It will resolve that again with an A query to get an IP address, and connect to port 25 of that host to send the mail.

In a world without spammers, that's how things would work.

In a world with spammers, mail servers block connections from random addresses like residential IP addresses.

Users (who want to send mail from home) have to resort to using forwarding hosts: their mail client is configured to make an SMTP connection not directly to a target mail domain, but to a configured host, like something run by their ISP or some commercial SMTP provider.

Suppose you want to write a client that can do email sending (SMTP), email reading (IMAP), contact book (CardDAV) and calendar (CalDAV) interactions.

SMTP/IMAP autodiscovery is limited at best, and CardDAV/CalDAV autodiscovery nonexistent, I think, so new users will have to find the details for several things, which is a big hurdle—or else you’ll have to recognise and special-case individual providers, which basically means Google and Microsoft get a massive unfair advantage. By contrast, JMAP handles autodiscovery of all this: type in an email address, and it finds the JMAP endpoint, which handles all of the stuff. (I will admit that this is currently more aspirational than real: to begin with it requires a DNS SRV record and/or a /.well-known/jmap HTTP response; and the means of authentication is deliberately unspecified at this stage, so we kinda need to wait around to see what providers settle on for authentication, with some kind of OAuth arrangement probably most likely.)

And then perhaps your client is webmail; if so, you simply can’t use IMAP or SMTP. I guess you could try talking them over WebSocket or something like that (still requiring a proxy of some kind, even if a pass-through one), but that’d be painful; instead, everyone rolls their own thing, and so there’s never any webmail cross-compatibility. In JMAP, by contrast, the only thing you can’t do from a browser is looking up DNS SRV records. Everything else works, so that you can run your own webmail client that talks directly to the origin server. This allows you to disentangle the provision of service and software, which is very desirable for decentralisation.

Well, now you want your client to produce notifications when new messages come in. If you’re writing for a desktop platform, fine: you can keep your IMAP connection open. But if you’re on a mobile platform, you probably can’t do that, and certainly can’t reliably, so… you’re stuck needing some kind of proxy and server component again. No good. But with JMAP, you set up a push subscription and it works just like any other app, without needing to keep a connection open.

So there are three simple and concrete advantages of JMAP over the legacy protocols. JMAP actively bolsters decentralisation, in email providers, in domain names, in contact book and calendar support, in webmail, and in mobile notifications. There are other functional advantages too. JMAP enables some moderately complex batching that makes some sorts of realistic operations vastly faster than IMAP due to being able to skip many round trips. And JMAP’s pleasantness to work with directly should not be understated: no one wants to work with SMTP or IMAP directly because they’re painful protocols, and so of course all of that stuff tends to get extracted into a single library that protects you from them; by contrast, working in raw JMAP is pleasant and easy, which can genuinely open you up to doing things that would have been too painful to do through your IMAP library. And if you use JMAP, your mail client can skip worrying about MIME parsing (which is landmine-filled territory) if you choose. You can write a useful and complex standalone email workflow with nothing more than HTTP and JSON libraries.

> The underlying idea behind JMAP is that the future consists of only large mail operators who somehow forward mail among themselves. Routing to SMTP servers is gone, and so is self-hosting, mostly.

This is all completely wrong: JMAP is for client–server communications and doesn’t replace server–server communications, which still use SMTP. JMAP does not prop up email monopolists.

> If you want developers to interface with it, you can't hide it: you have to document what the requests and responses look like.

I have no idea what this is about. The spec shows examples.

> The "open standard" rhetoric has good optics; even more so with the IETF rubber stamp.

There was no IETF rubber stamp (which I take you to be using as a pejorative). There was collaborative process with people from a variety of companies who took what Fastmail had designed for their own use and wanted to share, and made it considerably better.