All of EJB is certainly optional. Sun's goal was to provide container services to automate a lot of drudge work so developers could focus on the business. It's open for debate whether they made things so complicated that they missed the goal entirely.
I don't know of anyone using stateful session beans. It's a pretty neat idea but has never seemed worth the effort to me. Anybody?
More people abandon container managed entity beans every day, I think. There are plenty of alternatives. The next EJB standard version has a persistence layer that is very similar to Hibernate.
Still the EJB container does provide a nice set of services in transaction management, security, remote access and so on. You'd have to look at the full set of features, think about how much work it would be to roll your own and then decide if you want to be in an EJB container or not.
I've worked on two systems that had a single stateless session bean gateway to all functionality. Everything else was written in POJOs with minimal references to EJB services. Those architectures chose to use the transaction and security and such, but most of the time the coders were completely unaware of EJBs. With a good measure of dependency injection (ala Spring or something like it) you can build POJOs that can run outside the container for
testing or even reuse in a non-EJB project.
Mark ]