No, the efficacy of the direct GL canvas native bindings and the view composition architecture are why it's efficient. Yes, there's little runtime language overhead because it's AOT compiled, but that alone wouldn't cause it to win over another AOT compiled mobile device strategy, such as an AOT xamarin project. (And all the other points in that article apply equally to xamarin, for example; and some are just opinion like the xml vs code for layout debate) I'm sorry, but I don't see how any of flutter's real performance wins are truly tied to its' choice of language, and it's a competitive market. I'll be happy if I'm proven wrong in a year or two's time, however.

(Flutter TL here, I wrote large parts of the Flutter framework.)

Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.

In profiles we see about half the time spent in Dart and half spent in the underlying graphics bindings (it varies wildly per scene, obviously, but as a first approximation this is roughly true). If Dart had been less efficient, then we'd quickly see it in the profiles as a problem. I doubt other languages could have achieved similar results without sacrificing usabilty (e.g. we could get faster performance using C++, probably, but good luck writing a usable reactive framework with manual memory management).