Having spent a lot of time looking at/comparing/building Web 1.0-style server-side frameworks, I've since switched to GWT and really like the client-side model. It'd be hard for me to go back to munging HTML/data back/forth from the stateless server.
Of course, GWT is not perfect. DevMode needs to be faster, and they need to integrate scala-gwt. :-)
I wrote a Backbone-like framework to deal with some of the boilerplate (http://www.tessell.org), especially if you're doing MVP. I don't quite have a solid DTO story down yet, but overall I like it.
If I had to use a server-side framework again, I really liked Click (http://click.apache.org), as it is component based, but has source code you can actually read (vs. both Tapestry and Wicket which are too big/magical IMHO).
I don't know about 'best', but I certainly can tell you what we've done for our latest project, Voost. https://www.voo.st/
Google App Engine cause we hate doing sysadmin work. Objectify. Cambridge Template Engine with JEXL. RestEasy/HtmlEasy. Jackson. Guice to bind it all together. Front end is heavily CoffeeScript, Handlebars, Jquery, LabJS, customized bootstrap and various other libraries. We've got a credits page full of links to the above projects... https://www.voo.st/about#credits
Overall, I'm pretty happy with this choice. We've had to do some weird and semi-complicated stuff to integrate it all together, but at this point, it works quite well.
I've never gotten a chance to try out Play, I'm no longer doing any JVM stuff... but back when I was a Java guy, my favorite java web framework was Stripes: http://www.stripesframework.org/display/stripes/Home
I've never really understood why Stripes hasn't "caught on." It's simplicity is wonderful.
Stripes was pretty much subsumed by JAX-RS. There are a few rough edges surrounding html rendering (thus microframeworks like Htmleasy) but for the most part, Stripes is no longer necessary.
Most of the history of Java web frameworks focused on ways to make form processing easier. Nobody (sane) does html form processing anymore. The "framework" needs to be little more than a way to render html templates and an rpc mechanism.
I was doing basically this before moving to Play 2. I just found there was a lot you had to decide for yourself. You had to pick a persistence layer, roll your own xsrf protection, do your own integration of a JS compiler/minifier, etc. I had something pretty good working, but got tired of having to write the code for every new technology integration myself. The thing I like about Play 2 is that I have an entire community helping me out with these things.
Has Wicket changed to not require so much code? I wrote a handful of apps using Wicket 1.2, 1.3 and 1.4 before realizing I was writing thousands of lines of code to update UI models and backend models that shouldn't be taxing me so much.
Used Play for a few projects, but don't like that 2.0 is more or less getting rewritten... don't like Spring... not sure what is left (JEE6 and JSF2? God I don't want to use JSF again unless it changed significantly)
Re Wicket: have a look at PropertyModel and CompoundPropertyModel. You'll lose a bit of type safety, but it will seriously cut down on boilerplate code. In particular it helps map wicket:ids to your Java bean hierarchies by following simple conventions.
Somehow I managed to use Wicket for well over a year before realizing the benefit to this approach.
IFF latency isn't an issue, just chop the front-end and expose services from the Java container (where it shines and makes perfect sense) and use a suitable non-Java front-end tech to create the presentation layer.
Of course, GWT is not perfect. DevMode needs to be faster, and they need to integrate scala-gwt. :-)
I wrote a Backbone-like framework to deal with some of the boilerplate (http://www.tessell.org), especially if you're doing MVP. I don't quite have a solid DTO story down yet, but overall I like it.
If I had to use a server-side framework again, I really liked Click (http://click.apache.org), as it is component based, but has source code you can actually read (vs. both Tapestry and Wicket which are too big/magical IMHO).