The problem with this and the wat talk is that

* you don't actually see the case-space (value space) of all the comparisons that do work as expected, and

* you don't a sense of what is the likelihood that these sort of comparisons would happen in real world code

Some of them like the empty string are likely to happen from user input, but Typescript mitigates those by forcing you to e.g. use Number(inputField.value) to conver to number and complaining about the assignment otherwise.

Others pretty much never ever happen - instead of comparing 1 or -1 to true, you're more likely to use if (val) which casts to boolean, and the truthy table is different from the equality comparison table (it makes a bit more sense)

Most of the real world comparisons are to non-empty strings or numbers, and those are only equal to arrays in some cases - but its rare for an actual array to be produced by anything. Things you know are arrays already you don't compare using "==" to begin with.

So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much.