I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least.
IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. http://jmap.io/#why-is-jmap-better-than-imap lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of.
IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do this than there are IMAP clients—and almost none that are any good. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too.
For authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph—they’ve already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really is “all that”.
Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to.
IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn’t make something like the FastMail web UI speaking IMAP; it just wouldn’t work in too many places. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP.
JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser.
Don’t forget that JMAP replaces IMAP and SMTP for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users.
The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You really can’t do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there.
I have no interest in making a realistic MUA with IMAP/SMTP, because I know that I would spend weeks on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs.
Oh yeah, I just remembered another absolutely massive thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for some ESPs, whereas with JMAP that groundwork will take maybe another whole hour.
Seriously, JMAP is a big deal.
---
¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging.
² I’m delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.