Good question. The obvious answer is that the spec says so. Not very satisfying I know. My guess is that it is because entity beans are not supposed to be heavy on business logic, but rather they are just a glorified method for entity-relationship mapping. Admittedly they have taken on a greater role than that in the latest specifications, however, given that Session beans are the classes that are client accessible and are supposed to have the business logic, it makes sense to put the transactions there.
In addition, it would be problematic if your entity beans were committing transactions while the session beans that use them are trying to roll them back. Since entity beans are meant to be used by session beans, it could cause some bizarre behavior.
Finally, I suspect the fact that entity beans are single threaded singletons, really, could cause some unpleasantness if the bean managed its own transactions incorrectly. The EJB spec is written, with some successes and some failures, to prevent you from shooting yourself in the foot. I think this restrictions is one such example.
In general, there is very little you can do with bean managed transactions that you couldn't do better with a composition of session beans with container-managed transactions. Just my opinion.
This was first published in January 2002