The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture.
In theory you could use Javascript as that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.
As an example, Portable Native Client is "proper byte code" (simplified LLVM IR), but client-side compilation takes multiple times longer then AOT-compiling the same code from asm.js (the NaCl team is working hard on improving this though). The download size is also almost the same (if compressed). Performance isn't that much better either, so for every practical purpose "real" byte code isn't automatically better then sending (compiled and compressed) "source code" over the wire.
I'm even getting worse startup times for a "cold start" for the same code compiled to native OSX then for starting the same demo as emscripten version, (presumably because the native version first needs to load a lot of DLLs).
On the other hand, because PNaCL is a sane IR, its composeability and implementability vastly exceeds that of asm.js, which requires not only a full JavaScript stack, but additionally, a complex JavaScript JIT system capable of executing it with additional asm.js-specific optimizations.
I can take PNaCL today and deploy it on alternative stacks, irrespective of the web stack. I can inter-operate cleanly with alternative libraries and environments, I can adopt efficient host platform ABIs, I can run it with a sandbox or without. I could even use it as a generic cross-platform sandboxed in-kernel driver layer.
Moreover, should NaCL/PNaCL be successful, there exists the possibility for optimization on the silicon-level via the introduction of new instruction sets that optimize for in-process sandboxing of untrusted code, much in the same way that trap-and-emulate VMs led to much higher performing silicon-implementations of the same ideas.
Issues of performance can be solved given a well-designed system that applies only as much complexity as is needed, at the level that it is needed. asm.js is a hack inserted at an inappropriate layer of the technology stack; NaCL/PNaCL is a coherent compositionally-sane design that opens the door to later optimizations and significant improvements of the underlying technologies on which it rests.
If there exists a tool that compiles your language of choice to JavaScript, and the stuff you write in your language of choice works on modern browsers and is stable and performant, why do you care that it's JavaScript being compiled to and not byte code?
Because JS will always be compromised by being JS shoe horned into a role it wasn't designed for and not byte code optimised for the purpose at hand.
Shoe horning technologies into roles they weren't intended for could describe the entire scope of why the Web sucks (e.g.: HTML mixing presentation with semantics).
In theory you could use Javascript as that thing, but it wouldn't be very efficient. On the other hand, what you could do is create a compiler that compiles to both bytecode and Javascript, and then give the Javascript to older browsers that don't support bytecode yet.