Fundamentalmente, se o sistema de tipos estiver lá, o programador tem que lidar com isso. Ele pode ser bastante "flexível" (ou seja, fica fora do seu caminho em situações em que o sistema de tipos como o Java seria uma dor) e implícito (portanto, as anotações de tipo podem ser omitidas quando não agregam valor), mas o programador tem que lidar com isso. Mesmo que todo programa prático e correto não precise de nenhuma anotação de tipo e "simplesmente funcione" (IMHO), os programadores escrevem programas errados - pegar esses erros é o objetivo de um sistema de tipos, afinal.
Apresentado com um erro de tipo, o programador precisa entender o sistema de tipos para entender o erro. Em geral, os sistemas de tipos que permitem mais implícita e são mais flexíveis (no sentido acima mencionado) são mais complexos e difíceis de entender. É claro que, para um determinado grau de implícita e flexibilidade, um bom design e boas mensagens de erro podem fazer a diferença, mas há um limite. Isso não quer dizer que isso seja um mau negócio, mas é um compromisso.
Na prática, os sistemas de tipos que você nomeia não cumprem a condição acima de programas corretos "apenas funcionando". Você pode argumentar que eles impõem um estilo de programação melhor, e eu concordo, mas eles rejeitam programas válidos do estilo que as pessoas realmente escrevem. Isso causa atrito. Há muitos upsides, é claro, mas você parece sugerir que se pode simplesmente parar de escrever JavaScript e obter todas as garantias de correção de graça. Isso não é verdade, é preciso entender o sistema de tipos e se acostumar com os programas de fraseado de uma maneira que o sistema de tipos entenda. Por exemplo, em Haskell você não pode ter apenas subtipagem e herança. Este é um trade-off que compra certas vantagens a Haskell, e é uma escola de design perfeitamente válida, mas também dificulta a implementação de projetos diferentes.