A probléma abból adódik, hogy a relációs világ (a SQL nyelvvel együtt) teljesen más, mint az objektumos világ. Az ORM rétegek ezt a különbséget próbálják áthidalni, de valójában más modellt tervezel egy alkalmazáshoz, ha OO oldalról fogod meg, mintha relációs oldalról.
Én nagy ORM fan voltam mindig (elsősorban Hibernate/NHibernate-et ismerem), mert sosem rajongtam az SQL-ért. Kellett nekem is sokszor adatbázis teljesítményre optimalizálni, ami azért nem lehetetlen, ha nem félsz belenyúlni egy kicsit pl. a Hibernate mélyébe. Nekem legutóbb a join-okat kellett optimalizálnom illetve bevezetni group_aggr függvényt a JPA rétegbe, nem megoldhatatlan, és a végén sikerült csúnya hack-ek nélkül, de kellett Hibernate Dialect-et bővítenem.
Amitől az egész relációs-objektumos ORM probléma lesz, az hogy sokszor akkor is ORM-et használnak a fejlesztők, amikor nem kellene. Az oka ennek az, hogy az ORM réteget már ismerik a fejlesztők, nem kell SQL-el foglalkozniuk, bevált sok esetben. Így - mivel van egy jó kalapács - mindent szögnek néznek.
Azt viszont ne felejtsd el, hogy nem ért mindenki mindenhez, illetve nincs mindig idő hatékonyra csinálni. Az ORM rétegek meg igenis jól vannak megírva, ahhoz képest hogy mekkora szakadékot kell áthidaljanak, egészen jól teljesítenek. Csak hát ez nem mindig elég (vannak csavarok is, nem csak szögek...)
Ja igen, van még egy előnye az ilyen ORM és egyéb rétegeknek: az alkalmazás kódját lehet SQL motortól függetlenre készíteni, ami kimondottan kedvező a tesztelés/tesztelhetőség szempontjából. Ezt a saját custom lib-ed is tudja?