ORM sind immer dann Sinnvoll, wenn Du wirklich mit Objekten arbeiten kannst / willst / musst, und die Einschränkungen der Mapper hinnehmen kannst / magst / sie Dich nicht stören.
Zudem erkauft man sich Objektrelationales Mapping immer mit Einbussen.
1.) OR-Mapper sind immer darauf ausgelegt, das darunterliegende RDBMS austauschbar zu halten. Das heisst sie abstrahieren auf einen gemeinsamen Nenner und meistens gehen dabei
DBMS-Spezifische Spezialfeatures flöten, an die man einfach nicht ran kommt.
2.) Performance. Das ganze hin- und hergemappe und die Generierung der Statements kosten nunmal CPU-Zyklen und damit Zeit.
3.) Medienbruch. Die meisten ORM generieren Dir aus der Datenbank Klassen die Du benutzt. Du musst jedoch weiterhin in der
DB die Strukturen anpassen und dann die Klassen neu generieren. In Sprachen die Partial Classes unterstützten ist das nicht so ganz wild, weil hier dann eine Datei generiert wird und Deine selbst implementierte Logik in einer anderen Quellcodedatei liegt. Da Delphi das nicht kann muss hier mit Ableitungen gearbeitet werden, was die Sache nochmal unschöner macht. Ein gutes Zwei-Wege Systeme ist mir (leide?) noch nie über den Weg gelaufen.
In einer Entwicklungsumgebung wie Delphi, wo die Datenverarbeitung aber (noch) von Grund auf auf Tabellen basiert (TTable, Datengebundene Controls die Du nur an solche Komponenten binden kannst) macht das ganze keinen wirklichen Sinn, denn da kann man genauso gut Daten- und Tabellenbasiert mit arbeiten und kann auf den ganzen Objekt-Overhead verzichten.
Andere Umgebungen wie .NET, wo man auch am UI nahezu alles mit Objektbasiertem Databinding erledigen kann, oder bei Umgebungen die eh nicht viel mit UI zu tun haben (Backendsysteme in Java / .NET), sieht die Sache dann wieder anders aus. Hier ist man eher bereit, den Mapping-Overhead in Kauf zu nehmen um sich den ganzen
DB-Quatsch zumindest im Code vom Hals zu halten, und da macht das dann auch deutlich mehr Sinn.
Aus dem Grund basiert DataAbstract für Delphi ja z.B. auch auf Tabellen im Client und bietet hier kein OO-Interface an, wobei die .NET Version hier mit DALinq auch Objekte anbietet, auf denen man arbeiten kann.