The Web would also probably stop working and be much more of a pain to code if JS acted that way: http://i.imgur.com/76Wtthy.jpg
As for how painful it would be, your claim is a total fabrication. Other dynamically typed languages are a pleasure to program in without implicit coercions everywhere. JS is widely considered a pain. Coincidence it is not.
I find that is widely enjoyed by the "silent majority" and decried as a pain by a very vocal subset of developers. It's a little surprising that 1 + '1' is '11', until you spend a little time and learn the rules instead of fighting them - then you start doing your work in a way that uses that to save time. It's not great for everyone, but I like it - and I know a lot of other good devs who prefer the answer '11' (when you understand the fairly simple rules) to 'OMFGNOIQUIT'. I find "Number beats bool, string beats number" for implicit coercions covers 95% of cases where it would actually matter. For the other 5%, just type it in the console.
Because I like it that way, doesn't mean you have to as well - but it also doesn't mean that because you don't like (or even most of the commenters on HN) it it is "widely considered a pain".
You are omcpletely underestimating the complexity of JS's implicit coercions. If you haven't already seen it, watch the Wat talk [1].
Finally, the fact that you need the console to even understand the meaning of a code fragment is a perfect example of language failure.
Isn't that the case for every language with polymorphism? Even C, once you add function pointers to the mix.
I've certainly heard polymorphism and OOP criticized on these grounds, but unless you're a hardcore kernel or embedded developer, that ship sailed about 25 years ago. Everybody uses debuggers and log statements these days. Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.
My number one favorite thing about Go: you can look at a code sample in isolation in a large-scale system and know what it does.
Why? Every identifier is either lexically scoped or lives in a module. There are about 6 control structures and they all do what they look like they do. Operators are all defined over a small set of well-defined primitives, they can't be overridden. Closures, callbacks, and non-linear control flow are rare and obvious. There is no way for code to be skipped by exceptional control flow apart from the single escape hatch called panic().
It's really like no other language I've ever coded in. You can work in large codebases that are as clear as your average Go code, if you have strong guidance about what kinds of code complexity are acceptable and you are ever-vigilant about avoiding language pitfalls, but nothing is quite as freeing as knowing for a fact you will be able to parse someone else's code because there wasn't any way for them to write something you can't understand.
If you're disciplined, you can write solid, easy-to-understand code in any language, Javascript included. I've worked on million+ line Javascript codebases and been productive (as a developer new to the codebase) within 3 days. But this imposes trade-offs in verbosity and flexibility that are often not worth it for most (non-Google-scale) JS codebases.
I don't know why you'd think that. In a typed language, you simply look at the types and you know exactly the intended meaning of a code fragment ie. what inputs are needed, what outputs are produced, etc. That's not remotely the case for JavaScript due to its implicit conversions.
I really think the problem with javascript really boils down to the fact that it's still in beta and will never have the breaking changes necessary to move it to a 1.0 language (i.e . the ECMA committees commitment to not breaking the web). But, it's easy enough to get around that in new projects by using linters that get rid of the bad parts.
Duck typing for methods and such is fine if that's what you're into, but if you're checking for equality, you want type errors, period. Only like equals like. Doesn't matter if your language is statically typed or dynamically typed, equality means something very specific and it's very surprising when those expectations are violated.
There are a few other smaller issues that are nuisances, like not being able to actually check if a value is a number, but I think coercions cause the most headaches for discoverability and debugging.