* Things like progressive enhancement and semantic markup might not be totally impossible, but they're definitely not the focus of the framework.
* The back button is broken by default; there's a work-around but you're probably used to getting that functionality for free.
* The GWT compile cycle is LONG.
* You pretty much NEED to be using Eclipse (or possibly IntelliJ) instead of your text editor of choice.
* The final product probably won't feel like most web applications.
To be fair, people have written things like [quake2-gwt](http://code.google.com/p/quake2-gwt-port/), so you can get something pretty awesome in exchange for these tradeoffs. Also, if you loathe HTML and JavaScript, but you still need to get something up on the web, then GWT might be just your ticket.
History and back button support in GWT is very straightforward and trivial to implement. (http://code.google.com/webtoolkit/doc/latest/DevGuideCodingB...)
The default compile cycle is long as GWT is compiling for multiple clients targets (and potentially localisations). You can speed this up a great deal by reducing compile permutations to 1 (http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ...). You should probably also mention that you don't need to recompile in development mode.
Compile time definitely gets better if you reduce the number of targets, but it still totally dominates most people's build times.
Not needing to recompile in dev mode is definitely a big win.
FWIW, the compile time is still pretty long even with one compile permutation - and even while developing there is sometimes a need do do this (for example, changes to serialized objects.)
1) Reduce the number of targets (even if only while you are doing development) 2) Increase the number of threads doing the GWT compiling (-localWorkers).
Also, try running your compiles from a SSD. I haven't done this, but I've heard really good things about it (and GWT compiling sure is IO intensive so it's not surprising)
GWT's downside is that you're now making a rich client, and, IMHO, rich clients are a PITA compared to web 1.0/web 2.0 apps that just generate HTML on the server-side.
A rich client generally means you aren't sending HTML across the wire anymore, you're sending objects (json/xml/whatever), which adds a whole new layer of serialization and deserialization to your app. Even if GWT "solves" the technical side of serialization for you, you're (typically) still getting/setting data in/out of a lot of DTOs.
A rich client also generally means you're doing fancy validation/event driven coolness that, for me anyway, takes a lot more time to get right than just "here's a text box, have fun".
So, yeah, you'll get really slick apps with it, but I would be hesitant to use it if you're not certain you need a gmail-style one-page app.
You do have to be able to stand Java, of course. The upside of the use of Java is that when you're dealing with a large codebase the kind of tooling you get from Eclipse or IntelliJ is a big timesaver when refactoring. Things like CssResources and UiBinders are also very nice to work with, and do really help with keeping logic and presentation separate.
Some would claim that GWT is a bit of a crutch for enterprisey developers who "don't like working in the browser" but I'd say it's more for people who like working in the browser but don't much like Javascript. (FWIW I like Javascript, at least The Good Parts.) You do at the end of the day have to have a good understanding of how the browser works and what it is and is not good at to get the most out of it.
The biggest downsides for me are, in no particular order...
1) Very slow compiler when generating javascript. GWT compilation is the biggest chunk of our build time but not the majority of our code.
2) For a large application, load time in hosted mode is still pretty slow. Also hosted mode has some funky performance characteristics especially around serialization.
3) It kind of annoys me seeing lots of code working around a lack of reflection in GWT's version of Java, when the underlying Javascript runtime is completely dynamic and reflective.
I do have a lingering concern that GWT might be exposed to similar patent risks as Android, since it subsets Java and could not be considered a "compliant" java implementation. Not the same patents as in the Android case, obviously - since they were mostly VM related - but who knows what else Sun had in their cupboard.
If you have experience working with java, and know your way around the web, you should be fine. The only real limitation I'd come across was developing UIs, but this solves that problem.
There is hope, these guys have the Scala library compiling to "jribble" pseudo-source than then will get parsed by the GWT compiler: