From a semantics point of view: the post I originally replied to asked about compiled bytecode, not textual code.
From a deeper point of view: Theoretically you are correct. But in practicalities... Peresumably you get 2 benefits from compiling the code to bytecode:
* obfuscated source so people can't steal your secret sauce.
* faster execution because the compile step is skipped.
The second one has real practical limitations: for any major gain, the bytecode has to be in a format that allows fast execution, which usually includes taking out certain checks that can be done at compile time, taking advantage of lower level runtime stuff and in some cases, optimizations for the hardware arch below. This is all well and good, but when you have multiple engines interpreting the bytecode, this can be done in very different ways. In practice, to get from a robust bytecode to something that takes full advantage of the system, effectively invokes a second compile step from bytecode to the vm's internal representation. This is what a lot of JVMs do. I'm not sure anything would actually be gained in that case.
Further, a robust bytecode format would required, since there are already piles of hacks in the JS libraries we all use to handle various browser differences. To get a bytecode that allows this, we end up with something that looks more like a simple source code transform than any bytecode that gives significant speedup out of the gate. (and at that point, your obfuscation of the code starts to go away too - you could just disassemble it to something that looks like jsmin output).