In this way the attacker would be unable to gain anything useful from seeing the challenge or handshake packets, and the only remaining vector is some form of keylogger.
Or am I missing something here?
SSL has defenses against MitM attacks, and is implemented in very widely-deployed libraries, so if there's an implementation error you'll hear about it before it's used on you.
The drawback is of course that you need to have a signed key. That is the price you pay for MitM resistance. We're not supposed to use self-signed keys (which are free), even though they are strictly better than JS challenge/response hashing.
"Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted."
What am I missing here? Are people to cheap to purchase an SSL cert? Theoretically the PKI is only as trustworthy as the CAs but that can't be why people are acting like SSL/TLS isn't even an option.
If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.
You're missing the real solution: SSL/TLS.