The performance of stateful session bean was always great... 📎
I did these measurements, becauso of strange policies in a large scale project. The chief architect liked the stateless architecture very much and prohibit the usage of SFSB. ...but the developers needed the state and built a singleton which maintained the state of SLSB. A session id was passed between client and server -> so they built SFSB with SLSB and a singleton, which led to memory leaks :-).
The performance of SFSB was always great. The one and only possible issue is the replication in cluster (which is not needed, because SFSB are transient and the state is not transactional per definition). So if you have to maintain state SFSB or HTTPSession (jboss replicates both with the same technology) are great. The state of the business logic should be maintained using the SFSB, and the state of the presentation logic in HTTPSession.
The two stage passivation and long sessions could be a real issue for heavy loaded applications, but this is a general topic and mostly Java EE independent.
Btw. I do not expect differences in the performance of SFSB between the J2EE 1.3/1.4, Java EE 5 specifications, but there can be differences between the implementations of different application servers.
Premature Optimization Is The Root Of All Evil :-).
---Advert----
I described also the issues with state in my last (but german :-)) book.