EJB has a lot of baggage. Part of that baggage comes from the fact that it was targeted at the wrong audience. The other part was that the first two versions were utter crap.
If you look at the original EJB versions, the design was that an EJB developer could create a packaged solution that could be used within any EJB compliant container. For an in house shop, this level of abstraction was unnecessary. It was a perfect solution to make a thriving market for third party EJB component vendors. However, the Container vendors were overzealous in their marketing and were making tons selling their product as a viable solution for every day development. This would be the equivalent of building all of your application code as COM+ components.
For more of the background on the original J2EE spec, most of the vendors involved had CORBA servers and wanted to leverage those products going forward. The EJB spec was built over the IIOP protocol (actually Java RMI which was a thin layer over IIOP). CORBA had already been rejected because of its complexity, and EJB was just CORBA in disguise so it brought with it many of the problems that CORBA had. Actually, the abstractions of EJB made it more difficult to work with than a pure CORBA implementation would have been.
Once the rubber hit the pavement, people realized that performance with EJB was atrocious. With every call being a remote call and the difficulty of even getting the application up and running correctly to begin with, people quickly looked for alternatives. Hibernate and Spring running in a JSP container became the solution.
EJB 3 "adopted" this approach. But it's still a generic compromise that doesn't provide much benefit. There is still no 3rd party EJB component market so there's really no point in using an EJB container to build your solution.
Long story short. While EJB 3 is a vast improvement over the first two iterations, it still doesn't provide enough benefits to outweigh the costs.