I don't know why you're fixated on things like asm.js and C++ here when I didn't bring either of them up. Here's the deal:

Yes, C++ is a monster. Yes, asm.js might be doomed. I don't really care, because I don't like C++ and I don't have any intent to use asm.js. Given that, however:

C++ may be a monster but it's the monster that won. Worse is better, or whatever: C and C++ are tremendously prevalent languages and nothing anyone has done has managed to displace them even one bit. We've got new languages like Java and JavaScript that have managed to carve out footholds, but it's still a fact that when you grab a modern piece of software, it's almost always written in C, C++, or a weird C derivative (like Objective-C).

Note also that I've never argued here that the design behind closed doors is the problem, merely that it is a root of the problem. The design behind closed doors leads to poor/misguided design decisions being baked into a project and then cemented by years of engineering and derived decisions. You can certainly undo all that bad decisionmaking after you put your project out in the open, but it's not free, and it comes at the cost of severe resistance because people aren't excited by the idea of throwing out all the work they did. You can see this by looking at the mailing list for the W3C Audio group right now and observing just how hard it is for them to specify the Audio API that Google designed behind closed doors. An equally troubled API could have been designed in the open, but being designed behind closed doors is why it ended up with a narrow design that wasn't informed enough by a wider set of use cases and customers.

It's incredibly easy for software engineers to convince themselves that they are expert enough to make all the right design decisions and lock them in. We've seen it again and again. That is why it is important to work in the open and that is why Google's reluctance to do so early on causes lots of friction for (technologically stellar) projects like Dart and NaCL.

Were Dart already an established language player like C or even Java, these complaints wouldn't really matter, because at that point a language is a thriving, living thing that can evolve as time passes to become a better language and overcome its own faults. The problem here is that Dart is not there, it's not anywhere close to there, and it's not clearly on anything resembling a trajectory to there. If the software engineering community as a whole - not just people at Google - don't start learning from these mistakes we're just going to keep adding to a long, dire list of failed languages, libraries, and platforms.

Asking people to adopt a new language you designed for your needs, learn a bunch of new libraries, and rewrite all your code in order to run it in a small subset of available runtimes is simply not a winning play. As a developer I have literally dozens of great languages to pick from to write my applications in - Haskell, Scala, C#, Python, etc. Why would I pick Dart if the toolchain isn't there, the runtime isn't there, the libraries aren't there, and Google might abandon it in 5 years when it doesn't catch on?

And now you know why I'm writing a transpiler for an existing language that outputs JS, instead of hacking on something like Dart: Because I don't want to waste my time.