The container is not required to maintain a pool of instances in the pooled state. The pooling
approach is an example of a possible implementation, but it is not the required implementation.
Whether the container uses a pool or not has no bearing on the entity bean coding style
If container does not pool the entity beans, is there still a pool state for each ejb. If not, then the discussions about invoking finder home method on a ejb with "pooled" state will not make sense. And they should be not part of ebj spec. So I assume pooling or not pooling, there is always a "pooled" state in an ejb's life cicle. Am I right?
There is an conceptual oddity in EJB; home methods operate on the 'extent' (i.e. over the space of possible entities), component methods operate on specific instances within the extent. The spec is trying to allow room for how the container provider deals with extent-level operations.
It probably would have been better if once-upon-a-time the original EJB spec pulled the two kinds of functionality into different classes, but it didn't. As a result the java code for the extent operations (create, remove, find) lives with the component instance operations. What is a poor server vendor to do? Obvious choice - put some unused instances to work dealing with extent-level activities. Call that 'the pool' and - voila - you have a spec that talks about a pooled state.
An instance pool isn't the only way to deal with the issue. The container implementation could choose to have not just one subclass of your entity bean, they could have two... one for component instance operations, one for extent operations... but that is up to the vendor, and the spec is just trying to make it clear that container vendors are allowed to exercise such options in their implementation.