I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language".
If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock.
As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY.
Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.