Why the Session beans should not be re-entrant and the same way entity bean should be re-entrant? Why the container manages the thread synchronization then what is the point in having a separate property called re-entrant ?

Except for the JMS part of EJBs, Enterprise Java beans have synchronous interfaces, meaning that a response to a request on a bean must be sent before another request is sent to the bean.
Entity EJB can be shared between clients but Session EJB cannot.

Logically (but not necessarily implementation-wise in a container) this means that in a container there will be many session beans connected to clients and, hidden behind those Session Beans there will be much fewer Entity Beans.

This implies that the Entity Beans could possibly benefit from being re-entrant, meaning that requests to them will not be serialized.
Whether or not an application server will or can take advantage of the "re-entrant" field in the deployment descriptor is vendor specific.
Without going into too much detail, an application server that relies on the database for transaction management, f.ex., will likely not read the "re-entrant" field at all, because it will create entity beans on demand, not share them and thus not serialize access to them - making re-entrancy become a no-issue.

Even though session beans are synchronous, the fact that entity beans can be shared between clients means that an entity bean can receive a request that originated from a client B, while being buisy handling a request from a client A.
This means that the container has at least 3 ways of dealing with this:

• The container may store a single instance of the entity bean in the server's memory (RAM) and serialize access to the bean.
• The container may store a single instance of the entity bean in the RAM and take advantage of the fact that the bean's "re-entrant" field has been set to true and thus it will not serialize access to the bean.
• The container may ensure that there exists at least one instance of the entity bean per client that is actively sending methods to the bean. The entity bean is "cloned" in a sense and all of those cloned instances are mapped to the same record in the database. In this case the bean doens't have to be re-entrant, because a new client requesting access to the bean will get a new copy of the bean (although logically, all the clients appear to be connected to the same bean). The container also doesn't have to serialize access to the bean.