Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>. In GWT, you have 3 child nodes (text,
B, text) attached to a
P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As @Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.