It's not that they don't have to be re-entrant: they cannot be reentrant. The spec says "The container must ensure that only one thread can be executing an instance at any time" (EJB 1.1 Spec. 6.11.6). This
is partly to simplify development of the EJB: the bean developer needn't concern himself with concurrency issues. The other major factor is that Session beans are seen as extenstions of the client - multiple threads implies multiple clients, which does not fit with this view of an extension. Granted that stateless sessions are used more as facades over entities or service interfaces than as 'extensions of the client', the programming model (and the container's developer's task) are much simpler if we restrict session beans to one thread of execution at any one time. Also, because of the way that stateless session beans are pooled by the container, allowing two threads in one at once is not really needed.
Of course, the 'Gotcha' here is that session beans can't be 'called back' to from another EJB even within the same transaction. The reason that Entity beans are allowed to be reentered (if their deployment descriptor says they're built that way) is that there are (arguably) more cases when an entity might need to be called back than there are for sessions.