Can anyone who's in the "HTTPS without certificate verification is bad, m'kay?" camp (I'm not directing this to the author of the post I'm replying to) compare

Can anyone who's in the "HTTPS without certificate verification is bad, m'kay?" camp (I'm not directing this to the author of the post I'm replying to) compare and contrast that approach to the approach of SSH, where there is (usually) no such validation, and the breaking of which could have much larger consequences on global security then just HTTPS? Why not adopt the SSH model of accepting the server's cert at the first connection and then complaining loudly if the fingerprint changes? Or even go a step further and have browsers manage private keys (client certs) which identify the user? Some Linuxes already do this with SSH: if you have a private SSH key, an SSH agent will remember its decrypted form on first use, and use it for SSH auth. The client certs can be exchanged in a standard format throughout browsers and devices, and mobile phone-based two-factor-authentication can be used to increase security. So - bam, good enough MITM protection (sure, let the banks retain the PKI system), no passwords, and a completely ready implementation requiring no new standards. There is no requirement for the client certs to be "blessed" with strong identification with the person, so anonymity is achievable by having an arbitrary number of different client certs.