In general a good ORM solution should be easy to use and understand. It should promote the use of good design patterns (DAOs, DTOs, lazy loading, services, transaction boundaries, ease of configuration etc). It should be non-invasive - that is, it should not force you to extend special classes or implement special interfaces.
The EJB specifications fell over a lot in the early days leading to the mass migration away to the likes of Spring and Hibernate. EJB1 failed to adequately define CMP fields on the bean, EJB2 sort of implied that they should be abstract accessors rather than actual fields, which was just odd, and it wasn't until EJB3 that something close to what everyone actually wanted was created. By then it was too late, everyone believed EJB sucked and it took the JPA and JTA JCRs to put things right again.
EJB1 and 2 generally forced the developer to put all their persistence configuration in a bunch of XML files well away from the actual code that was using it. This lead to lots of confusion and buggy code. Other ORM frameworks learned from this and decided to use annotations instead. Big win for them.
EJB1 and 2 had very limited support for different kinds of relationships and how they could be implemented in the underlying relational database. All kinds of special interfaces had to be adhered to and the resulting code was hard to fathom.
Anyway, all that is in the past and we can look forward to a bright future with the likes of Hibernate implementing JPA and JTA. All very harmonious.