Yes, any concrete compilation target has limitations, including JavaScript.
For example, in JavaScript, there are no 64-bit integers, which can slow down some code. As another example, strings on .NET and Python are different, causing Python on the CLR to either behave differently or run more slowly.
I think the important thing to realize is that there isn't a "perfect" compilation target. What we really want is a target that is (1) fast on all languages, (2) portable to run on all OSes and architectures, and (3) safe to run in a sandboxed manner. There is no target I am aware of that maximizes all 3. All we can do is try to get close.
I would say that JavaScript is doing pretty well in that respect already (that is, like all other options, it isn't perfect, but it's relatively decent), and remaining missing features are being worked on.
> it's a shame that we aren't exploring other options.
I don't think that's true at all - such experiments have been done! We had or have ActiveX, Java, Flash with its multiple VMs, Silverlight/.NET, NaCl, PNaCl, and others I forgot.
Given the performance of JavaScript engines today, those experiments of other VMs don't show a big enough reason to prefer them. asm.js code runs fast enough to run AAA game engines, which is a very good test.
I guess what I am saying is that it seems like we are stuck with javascript for historical reasons and it's a shame that we aren't exploring other options. Of course, I can also completely see that sticking with javascript is the most practical option as well.