If you use stateful session beans, the EJB container manages state on behalf of your client, so there is no need to pass around an ID: It's more comfortable.

In your case it's OK.

Generally speaking, consider these items:

• Stateless services are sometimes a little bit easier to test: If you write a test case, you do not have to consider the side-effects on the state.
• If your stateful session bean holds cached data, you have to handle cache invalidation.
• If your session bean is @Remote: If client and server are not on the same JVM, each method call requires marshalling, and goes over the network.
• If you have lots of stateful sessions which consume resources on the server side: You already have two Lists there, and their number and their content will most likely grow over the time. Using a stateless setup, you can design an application where the state is only managed in the browser, for example.
• If someone else is using your comfortable stateful API, and you must change it later, you will have endless discussions.

For these reasons I always prefer the stateless setup using data transfer objects. But again, in your case it's OK.