In your second point, you've mixed up EJBObjects and bean instances. The container does indeed decide when bean instances will be removed from the pool, and calls ejbRemove() in this case. The EJBObjects are not in the pool.
True. However, I'd like to pick up what you said about the EJBObject living on until the client calls remove(). I'll stress again that this is how the client sees it
as per the OID, but the container is not mandated to destroy this object at all!
Really, it only makes sense for a client to call remove() for stateful session beans and entity beans.
I would be willing to concede your third point if you could envision a scenario where a pseudo-EJBObject, which isn't connected with a client and really shouldn't even yet be in existence, would be useful to a bean developer during ejbCreate(). I sure can't, and I haven't seen any discussion of why this might be useful.
You mustn't look to any scenario which I can envisage, what matters for the exam is what the EJB spec says. And the spec mandates that, for the methods of a stateless session bean, the following SessionContext methods can be invoked from ejbCreate:
getEJBHome, getEJBLocalHome, getEJBObject, getEJBLocalObject.