I've used tapestry for many years now, well before it became an Apache project. Tapestry was one of the early pioneers of having the UI generated server-side via a set of components a developer specifies in an XML format and then wires via events to translators, validators and business logic. If you've not yet delved into server-generated, component-based UI you're behind the curve.

A developer creates a template XML document representing a web page. The document is HTML which imports the Tapestry namespace. Developers then create normal HTML which custom attributes that turn these HTML elements into Tapestry components. A tapestry component is a Java class backed by its own (optional) HTML template. The web page also requires the creation of a Java class which provides the model for the web page - it makes heavy use of annotations to inject beans and specify properties that may be accessed from within components nested inside the web page's XML template.

It's extremely mature and well thought out. It is also very flexible and extensible so you're pretty much wide-open to do what you want. It would be a good framework to start gaining exposure to the newer UI approaches that are common today.
When you set it up correctly, the framework screams. It has a lot less overhead than many of the newer UI frameworks that are more popular and is designed for performance over many other priorities.

It hasn't seen wide-spread adoption and that is its greatest detractor. Why not? Back in the day, Tapestry did not become part of the Sun working group that drove the UI standards that emerged four or five years ago post Struts (JSF was a result of that which we'll discuss in a minute).

Tapestry can also be a bit convoluted, especially for the uninitiated and since there aren't good tools for it many have stayed away.

Velocity is a pure macro-driven framework, meaning that a developer creates a web page that is a mix of HTML and pseudo-XML tags that result in a call to a Java macro. The macro replaces the pseudo-XML element when the page renders and you're off and running. Developers can create her own macro's that get replaced.
Integrating Java data objects into Velocity is not as straight-forward as the other two frameworks at first-blush. The developer makes available to the Velocity engine certain Java objects from which the developer can gain access to the rest of the project's data model.

Not only is Velocity mature, it's got to be eight or ten years old by now, it's got a large and active community.

It's brain dead simple to get it up and running. The other two frameworks I'm reviewing take a ton of scaffolding to get the foundation up and then also require a lot more reading about the fundamental approach before a developer can start cranking code.

Velocity doesn't require as much discipline in the organization of the code and the architecture compared to the other two frameworks reviewed. This is a good thing if you're doing a simple project or prototype that you want to get up and running and not a good thing if you're doing an enterprise-scale site. I'm not saying you can't use Velocity for a big project. You can if you have the discipline to structure things in a well-defined architecture.

Like Tapestry, JSF generates UI server-side via a component framework. It differs from Tapestry in that the default implementation of the JSF spec that most use has the developer create JSP pages with custom tag libraries that provide the JSF components. The developer doesn't use standard HTML, instead embedding the custom tags provided by the JSF library. These components in turn are backed by Java classes that create the appropriate UI.

JSF embraces the entire Java stack of solutions and so its brain-dead easy to gain access to the model tier via "backing beans" which can be nothing more complicated than a POJO.

In the early days of JSF, many complained the framework lacked a complete component-set. This is no longer the case. JSF boasts one of the most complete set of components out there.

JSF was created by the Sun working committee process way back when by the who's who of the Java tool and framework industry - Oracle, Sun, IBM, JBoss, etc. It enjoys excellent tool support that helps offset the complexity of the approach.

The large community behind JSF continue to add-on frameworks and component libraries to extend JSF and provide every possible feature a developer could want. One of the better add-on frameworks, JBoss Richfaces, brings Ajax support to JSF: jump to JBoss Richfaces.

JSF suffers the same criticisms thrown at the rest of the enterprise-Java stack of recipes: it's bloated, it's complicated, it's hard to get up and going and wire it all together, it's hard to extend, etc. If you're doing a home-grown web page for yourself then I think I'll agree with you. If you're doing a web site for a large corporation that will have thousands of pages developed by a large team of engineers and that needs well-defined architectures with well-defined contract points and that will a long development cycle then this is the framework for you.