As far as I understand it (which is quite limited, I haven't been able to find a white paper or whatever about DMAP thus far), there's a fundamental difference in what layer of the stack security resides in.
JMAP is a vaguely IMAP compatible protocol, in that the mail storage is probably just Maildirs or whatever (with some indexes to make it fast). It is not a complete re-design of how email works. Encryption is just in the network layer between client and server; the server, if compromised, would compromise the mail (unless other encryption features are layered on top, as in the current email standards). That's a perfectly reasonable design decision, given how email has always worked, and the problems inherent in pushing encryption to the client...particularly if the client is a web browser.
DMAP is not merely "IMAP with JSON over HTTP" (JMAP isn't just that, but that's a reasonable enough short description). It's a fundamental redesign of a mail client protocol. Again, I haven't read the formal spec or anything, and there is no source for DMAP yet that I can find in the repo (DMTP is there, but no DMAP), but given what it's promising, it can't possibly just be layered on top of IMAP without significant changes. DMAP seems like a very long-term project; maybe years away. I don't know if there are any implementations, yet.
And, JMAP is so new as a public thing that I would guess it wasn't on Levison's radar until recently. It recently began the formal standards process, which is cool. But, it's also not really got any complete implementation (just a PoC proxy and an incomplete implementation in Cyrus with plans for Dovecot to get support at some point, too).
So, I think it boils down to a few things: JMAP doesn't solve the problem DMAP sets out to solve (which is end-to-end encryption with at-rest encryption on both ends), JMAP is also very new and has no production-ready implementations on client or server, and these are both open sourcing of projects developed as commercial tools (JMAP comes out of Fastmail development, DMAP comes out of Lavabit and Silent Circle).
Also, this does appear to have an HTTP server...so, probably something quite similar to JMAP, though certainly not talking the same protocol (since it pre-dates the publication of JMAP details). It could probably be made to support JMAP without a huge amount of work, since it already supports IMAP and HTTP.
If so, they haven't Open Sourced the implementation they're using (they have open sourced a JMAP-IMAP proxy that is pretty nice, but I probably wouldn't want to use a proxy in production). I don't recall what they've said about how they're using it, and if they're using it or some precursor to JMAP on their production systems.
JMAP isn’t all standardised and set in concrete yet (there’s an IETF working group for it [1]), so we’re not enabling JMAP for the general public just yet, nor is our branch of the FastMail web UI which uses JMAP deployed.
DMAP is designed to work optimally with encrypted message objects. I looked into making it a JSON protocol but JMAP didn't adapt well and was even more complicated than IMAP (if you can believe it).
