The overview says:
We have created the SWF for our team, not for world domination. If you are like us, the SWF may be useful; if not, perhaps not. For the past three years, we have used Struts to create Web applications for intranet deployment. Like many others, we wanted to move to an event model, such as JSF, and cobbled up Struts to support events for the short term. For reasons in common with other teams, JSF has fallen short of our needs. We looked at a number of interesting frameworks, Tapestry being the front runner, but ultimately decided to build a second framework on the same Jakarta Commons foundation as Struts. Using Jakarta Commons and fragments from the Struts source reduces the amount of new (read: unproven) code we inject to a minimum while still achieving our two primary objectives: event processing and IPU. This reuse also reduces the SWF learning curve for those already familiar with Struts. If this reasoning resonates with you, perhaps the SWF is a good fit.
A SWF contraindication would be an Internet application with very high numbers of users, such as The Server Side or Slashdot. The SWF must keep a modicum of session state even if you use client side Page state. Sites with high numbers of concurrent users may not be able to tolerate session creation for each user. As a rule of thumb, use the SWF for building Web applications, not Web sites.
What do you think of the approach and implementation?