Eu acho que é um bom método para usar ao construir algo como um framework, CMS, software de fórum, etc., onde você não controla os servidores nos quais ele pode ser instalado. Ou seja, SIM, você deve sempre recomendar o uso de SSL para logins e atividades registradas, mas alguns sites que usam seu framework / cms não o terão, então eles ainda podem se beneficiar disso.
Como outros apontaram, o benefício aqui NÃO é que um ataque MITM não possa permitir que outra pessoa faça login nesse site específico como você, mas sim que esse invasor não poderá usar o mesmo nome de usuário / senha combo para logar em possivelmente dezenas de outros sites em que você possa ter contas.
Esse esquema deve salgar com um sal aleatório ou uma combinação de sais específicos do site e específicos do nome de usuário, para que alguém que obtenha a senha não possa usá-lo para o mesmo nome de usuário em outros sites (mesmo sites usando o esquema de hash idêntico), nem contra outros usuários do site que possam ter a mesma senha.
Outros sugeriram que os usuários devem criar senhas exclusivas para cada site que usem ou usar gerenciadores de senhas. Embora isso seja um bom conselho em teoria, todos sabemos que isso é tolice confiar no mundo real. A porcentagem de usuários que fazem uma dessas ações é pequena e duvido que isso mude em breve.
Portanto, um hasher de senha javascript é o mínimo que um desenvolvedor framework / cms pode fazer para limitar o dano de alguém que está interceptando senhas em trânsito (o que é fácil em redes Wi-Fi atualmente) se o proprietário do site e os usuários finais estão sendo negligentes quanto à segurança (o que eles provavelmente são).