Because many legal constructs in javascript preclude various optimisations that could otherwise deliver near-native performance.
Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur.
Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours.
Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.
Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur.
Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours.
Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.