Quickly looking, the word list is 1626 words, which means 1626^3 = 4 billion combinations. I don't know how it works in practice but I would guess the initial sending communication is always quite short-timed...
It can be enough for PAKE. Depends on what your requirements are.
Edit: to be more specific: 32 bits means that an attacker has a 1 / 4294967296 chance of guessing your password. They do not get multiple tries, because that's not how PAKE works. It's akin to agreeing with someone that you will meet in the park and exchange a short secret phrase to prove your identities, whereupon you will exchange GPG keys with each other or whatever. You don't need 128 bits of security for the "meeting in the park" exchange, any short unguessable phrase will do.
That's right. But you'd have to attack an extraordinary number of transfers to have even a small chance of managing to get one by luck, and an attack of that scale would very quickly become obvious since everyone would have their transfers interrupted. I agree with you in principle though, I'd like to see just a bit more entropy.
Increasing the passphrase to four words would bring the odds up to 1 / 6,990,080,303,376. In magic-tunnel I believe there is a flag to change the number of words used by default. It appears that schollz/croc allows you to use your own passphrase, but not increase the default word size, that would be a good feature request.
You're quite right, of course, but keep in mind that magic-wormhole is using a much smaller wordlist, and in fact only has 1 / 65536 odds by default. The people writing software in this space don't seem to believe this is a credible threat.
How would tab completion work in a situation like this? Are the clients exchanging information about the passphrase over the same communication channel?
