For those who defend Tapestry with the suggestion that T5 absolves all of the issues with earlier versions, I would suggest T5 shows all of the flaws inherent with Mr Ship's previous efforts and adds a few more.
Too much stuff happens 'automagically' which is great when you want it to, and impossible to debug or fix otherwise.
Ship can't decide whether he wants code to express behaviour by convention or annotation, so supports both, documents neither very well and leaves teams to intermingle the two unless code style is ruled with a rod of iron.
The much vaulted claim to separate code and presentation is a deceit. Over simplistic conditionals in the view mean that any little change in UI behaviour has to be backed by a simultaneous code change. Components fragment any moderate sized web application into a plethora of interdependent widgets, each backed by three or more separate files which must be kept in sync. As all of the discovery is provided by package hierarchy, the codebase resists any attempt at management beyond the most simplistic strategies and all but the smallest project descends into a morass of hundreds of tiny files, impossible to navigate and miserable to debug. Without the benefit of explicit configuration to show which set of components contribute to a page or user action, you are left to trace through the dependencies until you happen to chance on the particular combination of components that have blighted your application.
By choosing his own conventions, Ship discards the great mass of useful development tools, particularly any providing vital validation of syntax and dependency.
Undoubtedly there are some very nice ideas there. Unfortunately, it's all or nothing with Tapestry. You can't chose the parts that work well and use other standard strategies where the framework is flaky. As he's thrown so many ideas into T5, there are bound to be some parts that don't fit the bill, and you just have to live with them.
Beyond that, further development on Tapestry runs at a snails pace (Ship seems to be devoting more time to yet another new framework, Cascade), and there are far too few contributors to the code base to keep it current or fix the omissions.
The bottom line is that development of any moderately sized web application is a pain. It requires a thorough understanding of the problem and all of the usual code management techniques to maintain a robust codebase. Frameworks spring up constantly, offering the possibility that much of this can happen automagically. In the simple 'Hello world' and student demo applications, everything appears to be wonderful. Scale up to anything larger, with a team working to deliver a maintainable web application, and the time saved is soon lost to dealing with an inflexible framework that introduces dependencies, unexpected 'features' and subtle assumptions about how your application should behave.