What prevents an attacker from using the hashed password (without decoding it) in his/her own requests?

hashed passwords are security theatre unless you have a challenge-response in which password is hashed along with a challenge from the server, otherwise you don't need the password - you only need the hash to gain access. I've MITMed a system like that before when I wrote a nice interface to the awful timesheet system at a previous job.

Mandating specific security mechanisms isn't future proof. Authentication is almost a side issue to JMAP itself. Getting a securely authenticated and protected channel is phase 1, sending and receiving the JMAP protocol items is phase 2.

The reality is that almost everyone is sending plaintext passwords over SSL these days, and the reason isn't that they hate you - the reason is that it means they can bcrypt the password on the server side.

An interesting factor about most of the challenge response protocols out there - the server side needs to know either the plaintext password or something pretty reversible about the plaintext password. That's how the server can have a little chat over the wire with your client about the shared secret that they both know.

Since my security protocol design credentials aren't that much greater than the average internet commentator, I don't trust myself to design, or the average client writer to implement, a fancy security protocol that nobody has used before. Tried and true please.