First of all, I would like to clarify that JSF isn’t exactly “going stateless” at its whole own. JSF just adds a new feature enabling the developers to create stateless views/forms on demand.
State saving is particularly helpful in dynamically manipulated forms with e.g. conditionally ajax-rendered parts. It remembers the state of the form across ajax based postbacks. In other words, it are those forms where you absolutely need a view scoped managed bean instead of a request scoped managed bean. In case of static forms tied to a request scoped bean, the state could easily be recreated on a per-request basis based on the view file and hence doesn’t necessarily need to be saved.
State saving has in case of server side state saving management however a cost in terms of server memory and session creation. Also, it has the additional disadvantage that a ViewExpiredException would occur during a postback while the session has expired. All of this can be solved by setting the state saving management to client side. But this has in turn a cost in terms of network bandwidth and lower performance due to serialization.
For example, in case of large websites covering a “public” and “restricted” section, you’d like to postpone session creation until the user has actually logged in. However, if you have a JSF login form on the public part, then the session would still be created by just accessing that page. This is an unnecessary cost if the form has basically no dynamic state at its own and is tied to a request scoped bean.
True, this cost is negligible if you have state of the art hardware, but it’s not negligible if you have relatively a lot of visitors and/or relatively poor hardware. In that case, measuring is knowing. Also, it is not always possible to go fully stateless, you’d lose the benefit and experience of having dynamically manipulated views/forms. You could however theoretically maintain the state on a per-request basis by fiddling with hidden input fields and/or custom request parameters.
Noted should be that statelessness has an additional disadvantage that it’s theoretically more easy to perform a CSRF attack if there’s an open XSS hole. Fortunately, with JSF2/Facelets it’s already very hard to have a XSS hole. The only way to get that is to use a <h:outputText escape="false"> to redisplay user-controlled data.