GWT doesn't get the fair share of respect it deserves. It's not enterprise java (j2ee and such), it's a toolkit that (amongst other things) lets you write and debug java, that gets compiled to javascript in the end. GWT is not modular in the same sense as jQuery/underscore/backbone/any other js library, that's its weakness but also its strength. Also, the same modularity of those libs is simultaneously its strength and weakness. You plug jQuery mobile and backbone, you have to hack the router. You plug backbone with rails, you have to hack backbone.sync; but that's okay, we're all hackers.
If you want to dismiss GWT because it's java that's ok, but there are alot of good reasons (some non-technical) to choose java instead of CS or whatever. In fact, if you look at the history of GWT, they had all these "enterprise" patterns such as EventBus or Composite Views, or any other thing that the backbone/spine/etc camps are re-writing right now.
GWT's RequestFactory feature particularly stands out as a huge productivity win for CRUD apps. Also, many of the weaknesses commonly associated with Java are diminished now that Google's excellent Java libraries (Guava, Guice) have become more widespread (with GWT versions also avaiable).
But I think people try GWT once, realize that the built-in widgets and panels look terrible and never look back. But some of the features that they don't get to trying are the features that really makes GWT worth using (the EventBus, RequestFactory, UiBinder, the excellent localization support, etc.).
GWT also doesn't preclude using any other JavaScript libraries. JSNI (writing native JavaScript within GWT Java source) is relatively easy -- I don't think it is uncommon to pull in JQuery in a GWT app for its effects, for example.
I know what GWT is. I agree that it provides out of the box certain functionalities that require a bit of "glue code" when using other frameworks.
However, the whole "just write a desktop app and we will turn it into a web app" philosophy doesn't seem very web-oriented to me. Yes, it works, it's easy, but if one day you want to change your client-side code (i.e. use a different framework or something) you'll most likely have to change the server side as well. It just seems to be too RPC-centered and too monolithic. But maybe I'm wrong.
You can do standard REST, or whatever you want with GWT. IMHO what really sucks with GWT is the language; Java really sucks sometimes and its full of ceremony. Also, I think they made the same mistake that the Swing guys did: they provided for a toolkit but they didn't provide a framework, ie, a standard way of putting it all together.
Anyway, you can check what the jBoss guys are doing with GWT, looks good even for Java: http://www.jboss.org/errai I think that if Java ever gets proper closures it will may be more of an acceptable solution for some cases.
If you want to dismiss GWT because it's java that's ok, but there are alot of good reasons (some non-technical) to choose java instead of CS or whatever. In fact, if you look at the history of GWT, they had all these "enterprise" patterns such as EventBus or Composite Views, or any other thing that the backbone/spine/etc camps are re-writing right now.