It's faster than "handwritten JS" because it's using a subset of JS that's already tuned to near the peak level of performance that you can achieve in JITting JS, which is tightly looped arithmetic with everything inlined working on SMIs. In V8, that's ~2.5x slower than the equivalent C code with optimizations. That's basically best case.

The problem is that it's still dynamic, and at any point a null can come along and force you to throw away a JITted function, so you have to have these checks everywhere just in case. Further, ECMA compliance does not require JIT compilation, which means to expect performance, especially on the web, is dubious at best. I can see merit to expecting performance metrics in something like Node.JS since it assumes V8, but the web does not have 1 JS engine, and the standard does not require such performance metrics.

The "benefits" of building a bytecode in that's represented in some subset of JS are essentially red herrings since they're effectively lies and the downsides are a lot more significant, IMO. Instead, we should be focusing on actually building a bytecode for the web such that all implementations are expected to have certain performance metrics.