Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.
As for team, in enterprise consulting, the concept of team is very shallow.
I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding, as every language will have its bullshit.
Only those edge cases merely expose functionality that can burn programmers on an everyday basis, like coercion rules.
It's not something that you have to get out of your way to get.
You do know there are many, many languages where that sort of obfuscation lay between difficult to impossible, right?
It's just a side-product of JS god-broken coercion rules and types, and those affect every statement one writes, down to the suggestion to use === instead of == for the most fundamental thing any language does: equality comparison.
The example is just meant to showcase how far the brokeness can be taken...
I tend to favor the mantra of be a liberal when consuming data and a conservative when exporting data and I find the == vs === does that very well. Sure it's a gotcha but no big surprise to most people that have been doing JS for any amount of time. I personally think it is a brilliant feature that save a lot of boilerplate when one understands the difference.