Can't vouch that this is the case with keybase, but where I've seen this done before, the hash is calculated in combination with some kind of time-based shared secret at both at the server and the client and then compared, with the theory being it would protect against the TLS connection is MITM'd; all the attacker would get is the hash, which is then useless as the time element isn't known.

IMHO, MITM would be better defended against using HSTS, certificate pinning, and perhaps DNSSEC.

Technically yes, but I would imagine they'd subsequently hash the hash on the server side as well.

I assume the extra client-side hashing is done to keep the plaintext passwords out of the application memory, not protect it in transit.

To clarify, this is just an assumption. I have not read up on the topic nor do I claim to be a security expert. This is just what came to mind when I had the same thought as you.

Anyone else know for sure?

The client's hash is the password but the password file contains salted hashes of the client's hash. An attacker that has the client's password hash can replay it, but they don't know the user's password. An attacker with the password file doesn't know any clients' password hashes or whether any of the password hashes are reused by different users.