I originally was supportive of this idea. Over time, the way I've handled null and undefined in my codebases have changed. I was just looking through a more recent project of mine, and was surprised to find out that I never once used the == null shorthand in there. Instead, whenever I needed to let a value have a nothingnness state, I just picked between using undefined or null for its nothingness state, and then stayed consistent to that choice, then whenever I needed to check if it was in its nothingness state, I would either use === null or === undefined, depending on which one I chose. If I was smart, I would simply always pick undefined, instead of randomly deciding between the two - maybe I'll improve on that in my next project.
I treated my public APIs in a similar manner - if you pass in undefined, it works as intended, and if you pass in null, I'd throw an error, as that is not one of the allowed types that the API expects.
The point is, there's ways to program in JavaScript which makes it so the == null trick isn't needed at all. There's a handful of other, minor advantages to programming in this alternate format - I won't go over it all here, but I did leave an in-depth comment in another thread where I exposed it in a lot of more detail.
So, guess I'm just saying that, while adding some sort of "? XXX" syntax would help a good number of people, I now believe that an even better solution is to introduce people to patterns that cause this sort of syntax to not be needed. (And to be clear - the purpose of using those patterns isn't to avoid the need of that syntax, the purpose is to benefit from the other stuff that the patterns provide, it's just a nice bonus that following these patterns means you won't feel a need for some sort of "? XXX" syntax).