As one of the people who worked on GWT, and have used other more structured frameworks (Dart, Closure), I have a strong affinity for systems with good tooling support, a consistent package management and module system, etc
However, I think what's missing is a recognition that there are different kinds of web apps. There are "application" oriented apps, primarily single page, large, and not content driven (gmail, docs, games, etc), and then there are page-oriented apps, like forums, content management systems, blogs, database backed forms/reports, etc.
The former lend them selves really well to the structured approach. You trade off simplicity and iteration speed for more of a "on rails" experience, but it helps for larger teams to collaborate on larger projects to have some restrictions on freedom and some mutually agreed upon consistent behaviors.
However, the latter page-oriented apps fit in a lot better with these microframeworks. And page oriented apps fit in with the original vision of the Web, they are documents, they have URL addressable, RESTful, hopefully, durable content, indexable by search engines, and linkable by anyone.
I think there is room for both and a sweet spot for different approaches. I often use several languages for specially suited purposes, like sed/awk/Perl for text processing, JS for small page oriented stuff or mocks, GWT for larger apps. I would not advocate GWT for people for building progressively enhanced page-oriented apps, even though I'm the author of GwtQuery and AngularGWT.
Using the right tool for the job often depends on context and personal preference. A lone hacker or small team can get by with doing a large app in hand coded JS with hand rolled build tools and module systems, but frustrate other people coming onto the project.
There is too much, IMHO, "one above all" thinking when it comes to development, and often, the original goals -- what the app is supposed to do for the end user, get lost in the zeal to build a cool framework or infrastructure for it.