> JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable
Well-defined maybe, but predictable? Not really. Intuitive? Absolutely not.
> There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken.
On the contrary, I don't believe that this is really the case. People can and often do run into these bugs in the wild because they take some input from either a user who does something unexpected, an API that returns something unexpected or a library that acts in an unexpected way and, rather than failing a logical assertion, the program continues with effectively junk data. Sanitising inputs can be surprisingly complicated too, especially when you don't know or understand the conditions you are supposed to guard against.
> Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead.
My point is not that the alternative is superior, for whatever definition of "superior" you are choosing, but instead that many statically typed languages will force you to think about that behaviour rather than proceed in ignorance.
> If you want static type checking when writing your program, then use a static type checker.
If you have to rely on what is effectively a linter to type-check for you to make sure your program won't do surprising things, that's not an incredibly positive indictment of dynamic languages as a whole.