I haven't gotten very far into the details, but the move to a stateless protocol seemed like an improvement (at least potentially) over IMAP to me. If the nmh approach was to daemonize locally, then it doesn't matter, but that way seemed a bit fraught to me. The basis of jmap seems to be batching requests into higher level (a reasonable approximation to mh-level, I perhaps naively thought) email concepts, so as to remove the need for a stateful connection.
As to GMail, there's some uncertainty about the scheduling, since a big step was apparently delayed recently, but it has to do with "Less Secure App" access:
https://support.google.com/accounts/answer/6010255?hl=en
AIUI, Google was planning on discontinuing LSA access late this year for gmail accounts (hosted GSuite accounts had a different timeline but the same goal). Instead, apps can apply for an app-specific "secret", but on terms that specifically disallow open-source code from shipping the secret. Emacs-devel was looking into it specifically because KMail supposedly had a way around the problem, which turns out to be "ignore the legal terms under a tacit agreement that Google won't overtly get mad", which is (as you might guess) less palatable to the GNU folks. The delay in the schedule has taken the pressure off for a bit, but the issue is still fundamentally unresolved.
From up here in the bleacher seats, it seems clear that the common webmail systems are moving strongly toward client lock-in in the name of security. Fastmail and JMAP looked like a potential alternative for the future. Yeah, they're not suggesting ditching IMAP yet, and clearly that would be a futile move. Similarly, they have a draft contacts and calendaring system using the same approach as JMAP, but they're waiting for use-cases to settle down (probably, for JMAP itself to settle down) before trying to solidify the specs.
Thanks,
~Chad