First, you have to understand how the beans are created and handled on the server.
For stateless session beans the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request. That means if the client does two subsequent requests it is possible that two different instances of the stateless bean serve the requests. In fact, there is no conversational state between the two requests. Also if the client disappears, the stateless bean does not get destroyed and can serve the next request from another client.
On the other hand a stateful session bean is closely connected to the client. Each instance is created and bounded to a single client and serves only requests from that particular client. So happens that if you do two subsequent requests on a stateful bean, your request will be served always from the same instance of the bean. That means you can maintain a conversational state between the requests. At the end of the lifecycle, the client calls a remove method and the bean is being destroyed/ready for garbage collection.
When to use stateless or stateful?
That mainly depends on whether you want to maintain the conversational state. For example, if you have a method that adds up two numbers and return the result you use a stateless bean because it’s a one-time operation. If you call this method a second time with other numbers you are not interested in the result of the previous addition anymore.
But if you want, for example, to count the number of requests a client has done, you have to use a stateful bean. In this scenario it is important to know how often the client has requested the bean method before, so you have to maintain a conversational state in the bean (e.g. with a variable). If you would use a stateless bean here, the request of the client would be served each time from a different bean, which messes up your results.