Some interesting ideas here, though. It's strange how much it looks like web development, with route handling for navigation etc.
When it started out it was completely uninteresting as a language and it's only selling feature was that it someday might find it's way in to browsers and that it compiles to JS.
Now that it's ditched the whole "replace JS in browser" the language has actually matured enough to the point where I would code in it outside of browser use case and the VM quality puts it in a unique performance/productivity spot. It is very much a hybrid of C# and Python in good ways with a decent package manager built in.
It's much more suitable to be viewed as a high performance Python replacement - unlike Go it's dynamically typed but offers optional static typing so the level of abstraction is much closer to Python - in fact I would argue that the static typing built in from start makes it more productive than python for project you need to scale up to multiple people.
But it was built by a VM team that knows how to get performance and knows the bottlenecks that prevent JS optimizations - so it's probably faster than V8 and the likes - not CPyhon level.
The VM/class library is small and embeddable which separates it from Java.
And finally the compile to browser was a design choice from the start so compile to JS is much simpler than existing languages (eg. Python/Java)
It's a great language for client side programming and it's usable in server side if you are already using it for client side and want same languages on both server and client.
Furthermore, TypeScript, Facebook's Flow etc provide stronger static analysis than Dart.
AFAIK the VM they are working on for mobile has green threads (aka. isolates), value types are irrelevant at this level of coding and interop is arguably better than standard FFI with their IDL/IPC system.
It's actually a perfect frontend language where you delegate stuff where you care about threads/memory layouts/performance/etc. to native code in whatever language that has bindings for their IDL.
TypeScript, Flow, etc. are JS type systems - Dart is a programming language - it's superior to JS in that it has sane semantics and standard library/collections, etc. It also has stuff like async/await shipping for a long time now (still not in TS official).
So it looks to me like a browser for applications in resource constrained environments (mobile). I see nothing wrong with this; We used to have innovations like this all the time but since the browser came along its been a bit of a tyranny of orthodoxy. Why not have a browser for documents and a browser for applications? I certainly don't like web apps in my browser for content sites. (They don't work at all, or the scrolling is all over the place or they burn up my battery).
For the moment though they seem to be clear that flutter is for application development on android and ios only and won't run everywhere. Plus Apple will probably never allow zero install (which knocks out half of my "browser for applications" theory, the other half being write once run anywhere)
I saw a talk that discussed this - it's deliberate. Flutter is intended to be a lot friendlier to web devs, to let them bridge the gap between mobile web and mobile native.