Speaking as one who has drunk the JMAP kool-aid (I worked for Fastmail for a few years): you sound like you’ve never tried to write an email client, or done much with email in general. Because the conclusions you’re coming to are completely back-to-front.

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.