Some TC39 members proposed this. It is in no way even discussed or decided by the TC39 committee yet. The fancy naming is proposed by some as a solution to prevent name collisions with the flatMap and flatten array methods used by an old version of the Mootools library. I.e. do not break the web.
The premise of the article that the more objects that mutate state locally are used the more complex and more difficult it is to reason about the system becomes is not true. The core principle of data encapsulation in OOP ensures your system will be manageable as it grows. This principle breaks down the complexity into manageable units of self managed simpler pieces of subprograms that are more easily to reason about. And as history has shown this approach did provide capability to programmers to build more complex and manageable systems.
As an event listener "function(e) {this}" is not the same as "(e) => this". With the regular function "this" points to the element on which the event listener was attached to while with the arrow function "this" points to the context (i.e. "this") of its lexical environment.
There are global symbols. You use Symbol.for() to either create or retrieve them. E.g. Symbol.for('hello') is available globally through the global registry. It should be noted that an already existing symbol e.g. Symbol('hello') is not the same as Symbol.for('hello') while Symbol.for('hello') === Symbol.for('hello')
Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.
Feature detection is not always enough. E.g. if a browser reports it has a required feature but that feature is buggy rendering it effectively unusable, then browser detection is necessary.
"The law of the passage of quantitative changes into qualitative changes"
According to Wikipedia it has its roots from ancient Greece https://en.wikipedia.org/wiki/Dialectical_materialism