Personally, for Java Web Frameworks there are two I like, for quite different reasons.
The first is Spring MVC. the rest of Spring can go die in a fire for all I care, but the Spring MVC part is quite nice. Used properly it allows you to very quickly write a 'low ceremony but high fidelity' server based system. If you make some simplifying assumptions you can have all the Ajax you want too.
The other is GWT. The authors continually harp on about saving us from Javascript inconsistencies and cross browser compatibility. And, to be honest, I think they have a very good point. Anyone who has done serious web work would have run into cross browser problems. There are some other benefits to GWT, such as moving client state down to the client, where it well and truly belongs. Also the ability to pass real, proper Java objects (or at least pretend that is what you're doing) means GWT would never even notice most of the 'heavy lifting' that other frameworks keep rupturing their disks over - such as parsing form parameters, or having to post forms to the server to get them validated only to have to go back to the client and recreate the failed form... (save yourself the round trip and a square headache).
Now, obviously I'm clueless, but to my untrained eye as a programmer the bits I'd need to put into a Lift app look similar in some respects to the JSP tag libraries. E.g. they are trying to get you to do the programming in the html or xml. The problem is that xml (or any of its bastard love-children) is absolutely awful for doing logic in, which makes it deeply unsuited for that task. The only JSP tag library that I remember being worth mucking around with was some sort of super-duper-table-thingy.
Oh sure, you might not need to use weird variants on tags like <h:form> or <f:u:form> or <z:button> or whatever it was, but is moving the weirdness from the tag into the style/class really that big of an improvement? It is still doing the programming in the wrong place, that is, in the html.