Because JavaScript is what every other browser supported, and browser vendors had two main priorities:
Making sure existing webpages worked (which requires JavaScript)
Letting authors do user visible things in their browser that they couldn't do in other browsers (changing programming language would be entirely hidden from users, except when it broke).
One particular comment summed it up nicely as to why there has been some resistance to that:
In this case the feature is exposing additional programming languages to the web, something without any real benefit to anyone other than fans of the current "most awesome" language (not too long ago that might have been Go, a year or so ago this would have been ruby, before than python, i recall i brief surge in haskell popularity not that long ago as well, Lua has been on the verges for a long time, in this case it's Dart -- who's to say there won't be a completely different language in vogue in 6 months?), but as a cost it fragments the web and adds a substantial additional maintenance burden -- just maintaining the v8 and jsc bindings isn't trivial and they're for the same language.
The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to.
Unless we want to turn webkit into the engine that everyone hates because of all its unique "features" that break the open web, a la certain browsers in the late 90s.
CoffeeScript is another example of an emerging client-side scripting language. However, rather than support another virtual machine in a browser (as Google is trying to do with Dart), it compiles to JavaScript. There are several other "compile X to JavaScript" that do that as well. emscripten is a good example of compiling LLVM to JavaScript.
So there are plenty of other client languages; they just all use JavaScript as an intermediate. I'd argue that should be what Dart does as well, though they have some room to improve.