In the spirit of bipartisanship, I'd like to start off by saying that Seam and Spring are both excellent and proven frameworks. With the advent of Spring WebFlow, Spring has entered itself as a serious contender in the stateful web framework space. You really can't go wrong with either one. So how do you decide then?
Personally, my feeling is that your choice of Spring vs Seam is going to come down to two factors: style of development and architecture. Seam espouses very thin layering, while Spring has always promoted the idea of having a data layer, a business layer, and a view layer. I was an adamant believer in separating out all of my logic the way that Rod Johnson recommended in export one-on-one
J2EE Design and Development and subsequent books...until I tried to use it in the real world. Our application grew monolithic extremely quickly, the very type of system that Spring had intended to demolish. It has been said, and I agree with it, that Spring looks frighteningly similar to an EJB container. I was torn over an idea that appeared sound and the reality of my application being very stagnant. That was, until I discovered Seam.
What Seam did was turn the current thinking on its head by encouraging you to stop thinking in terms of view->business->data for every problem and start thinking about the object, its behavior and its state. What type of object, or in Seam terms, component, are you dealing with? What type of state does it hold and what actions can it perform on that state or calculate from it?
Take that idea for a moment and realize that layers will grow organically (meaning they will happen naturally). Now you can take that component and bind it to a user-interface control...a button, a link, a select menu, or a tree. Taking this thinking allows you to get to your application's requirements very quickly. You can develop a component that is accessible from the UI, perform the least amount of work possible (as the agile developers would say) and then mature it as time goes on.
Let's assume that you buy into all of what I just said. What does Seam provide you, perhaps that Spring doesn't? First and foremost, Seam is a contextual container. What does that mean really? It means that first and foremost, Seam understands that the context of a component, its lifetime, is just as important as what the component does. In Spring, you primarily have a stateless container, where objects live for the entire lifetime of the container, and you have to bolt onto the side of that container the idea of shorter-term scopes. It just wasn't designed to accommodate the types of scopes you need in an enterprise application. Seam, on the other hand, has a wide range of scopes built right into its core: event, page, session, conversation, business, and application. This is all a natural part of using Seam.
But to give credit to Spring, WebFlow layers this type of stateful container on top of Spring, so more or less you can get away from Spring's legacy as a stateless container. The main downside of WebFlow in this regard is that it is tightly coupled with navigation (i.e., the flow), so you can't have stateful components and not have the stateful flow. Seam, on the other hands, lets you use stateful components in an ad-hoc manner (i.e., ad-hoc conversations), meaning you create the component on one page and perhaps destroy it later down the road based on a business case.
Putting aside that Spring WebFlow requires you to use a stateful pageflow, and comparing it with Seam on other bases, both solve the most fundamental problem in enterprise applications, management of the persistence context. The persistence context (e.g., the JPA EntityManager or Hibernate Session) is a stateful component. It was intended to remain open for the lifetime of the use case in which you are modifying the entities that it retrieves.
Case in point. You select a record for editing. You modify that record. Then you save it. The persistence context should remain open for that entire use case. Then, the ORM tool (e.g., JPA or Hibernate) can automatically detect changes and push them to the database. Better yet, it can detect when the database has been altered in the interim and prevent those changes from overwriting someone else's changes. There are a whole host of other features, such as persistence by reachability, that simply make the task of database saves and updates completely automated.
But where Seam really steps ahead is in its support for rich rendering. It embraces Facelets and the Unified EL (extended with extra Seam goodies) to give you an XHTML-based approach to creating all of the following:
PDFExcelRSSChartsGraphicsEmail (with attachments that include any of the above) On top of all that, Seam embraces
Java EE so that you can take those certifications that you have an apply them in a more effective manner. Seam is not asking you to abandon Java EE, but rather looking for ways to take it to the next level. There are very tight integrations with many of the Java EE services, such as EJB, Timers, and JMS, that work just like any other Seam component. It even has strong integration with Spring, so that you can treat Spring as though it were a consumable service.
I'll close by saying that we are lucky to have both frameworks as choices. If you talk to the Spring developers, you might end up using Spring & Spring WebFlow. If you talk to me, you might end up using Seam. Personally, I can tell you that I have used both and my most successful projects were those that I developed in Seam. Maybe it suits me better, or maybe it is just a better approach. That's really for you to decide.