=== wasn't introduced until ECMAScript 3 in 1999, originally there was only == when the language was created in '95.
The accepted wisdom is to prefer the newer === in the interest of clarity and consistency. With ==, it's easy to forget about one of the types it overloads (e.g. string vs. number) when making changes to existing code, and correct-looking code may behave unexpectedly for one of these types.
Other language features cause other confusions.
Quotes generally boil down to arguments about escaping, and have good reason for existing. Having a rule for when to use what quotes should be pretty inferable from when you need to use what quote to escape the data in question.
New array vs literal is more a pure aesthetics issue, and I can only really say, choose whatever you think the majority of people would read faster. Don't be different just to be different, and move on.
Take, for example, JavaScript's double-equals == versus triple-equals === comparison operators. (I already know you have a strong opinion on these!) The language designer saw fit to include both. Now, if I introduce one bug where I need to use === explicitly instead of ==, should I advocate for a ban the use of == across the entire program? How about if I introduce this bug twice? Three times? What if I've only heard from a senior dev that triple-equals is "bad"? Or should we test the least-experienced member of the team and let their understanding make the decision for us? What happens when that team member gets more experience, do we lift the ban?
Double- versus triple-equals example is probably one of the most clear cut trade-offs and worth exploring. What about all of the other rules? Double versus single quotes, for example? What about declaring arrays using array-literal syntax versus using the new operator?