Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support.
IE6 is irrelevant. The topic is modern browser with native Dart VM vs. without.
We're talking averages here, not pathological edge cases. Java has a 64-bit long type which JS doesn't support. GWT supports longs. In theory, GWT code should run slower, in practice, because GWT contains an optimizer, it runs as well, or faster, than hand written JS, simply because very few code bases have hot paths dependent on long arithmetic. For example, I've actually ported popular JS benchmarks to Java, ran them through GWT, and the result was faster.
Sure, would you be able to concoct applications for which Dart and Dart-to-JS have a large divergence? Yes. Will they be the common case? Probably not. I can concoct normal JS applications today which show high divergence between Chrome, Firefox, and IE, because of all of the JS VMs have different weaknesses, different optimizers, different garbage collectors. If you're writing applications that are so CPU bound and performance critical (e.g. games), chances are you're going to run into other portability problems too.
Most of this worry over runtime performance I think is a red herring. The real difference will probably be in startup time.
Don't change the subject. The topic is not productivity as you seem to imply here. Also, JS engines are not hard to track super-scalar CPUs. A compiler can target one JS VM (e.g., V8) but then you're locked in. All the current JS VMs have peculiar optimization faults, some worse than others, many completely disjoint across VMs. No one has a compiler targeting each to best effect.
Hand-coders can do well in general against current JS trans-compilers, but that wasn't my point.
The point is that if you actually need bignums, a JS emulation will be slower than a native Dart VM built-in bignum implementation.
"Most of this worry over runtime performance I think is a red herring."
The "worry" (such as it is, or was) was over Google's politics, not its Dart-to-JS compiler's generated code performance in isolation. Pushing a native Dart VM into Chrome, rewriting major Google apps to use Dart, then seeing if that creates market pressure for native Dart support in other browsers, was all suggested or even explicitly called out in the leaked memo. That was the "worry".
But it sounds like a native Dart VM in Chrome won't be immediately released, and the Google web apps written in JS or Closure won't be rewritten quickly. I don't know. Maybe you do -- do you work for Google?
GWT has supported Java's BigInteger/BigDecember, and it's never been an issue.
(For the record, since it is no secret by searching my handle, I work for Google, but I do not work on Dart. I specifically work on the GWT compiler, and do not speak for the Dart team nor represent their views, nor am I really representing anything, but my own biases here given my experience with trying to develop high performance Javascript games both in the browser and mobile)
If, as the leaked memo asserted, JS's lack of more than one number type is "unfixable", and we now see that Dart's fix is to add bignum as well as double, then bignum must matter. Else why do bignums in Dart?
This ignores the live bignum strawman on the ecmascript.org wiki, which Googlers on tc39 failed to champion.
If your argument is that bignum literal and operator syntax, not bignum performance, are what matters, I am with you -- but then why did no Google rep on tc39 work to advance the bignum strawman?
You can't have it both ways. It looks like some Google heavy hitters focused only on Dart as if it has a native VM, and not on Dart as a source language for JS, which implies certain obvious extensions to the ES standard.