I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere).
I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the 'already wrote a JMAP email client' case. Virtually any other case would rather stay with widely supported protocols?
If "newer = better" was my thinking, I'd be all for these new protocols on top of JMAP. But I actually think they're useful only in a limited context.
JMAP is better than IMAP because IMAP is a too stateful design, the IMAP/SMTP distinction allows for misconfigurations where sending doesn't work, has dozens of extensions where key extensions are inconsistently supported, doesn't have as many batched operations, etc. One could make an effort to improve IMAP - but the effort to do this consistently in server software would likely be comparable to adding JMAP and the result worse...
OTOH, the new protocols intrude on areas that go far beyond email software (you're very unlikely to get support for these in older Androids/iOS/Windows even if the modern OSs ever consider them), and don't offer as much as JMAP offers over IMAP. The cost/benefit is worse. They may make sense for a JMAP email client but IMHO not elsewhere.
I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the 'already wrote a JMAP email client' case. Virtually any other case would rather stay with widely supported protocols?