Software detective: software quality expert, experienced big data practitioner and performance specialist
ORM, and more importantly Object Relational Impedance (ORI) have fascinated me for the last 20 years. Back then I had plenty of time on my hands (having sold my shares in a software house I started back in the 90s) so I spent a few years developing an ROM (Relational Object Model) which (see OP below) is entirely devoid of magic. Since then I have gradually come to an inevitable conclusion: that taking data structured as relations (tables), turning it into objects for use in back-end software, only then to extract data from those objects to show them as tables in front-end software is a complete and utter waste of time and effort. So now, after 7 years of experimentation, my colleagues and I have chosen to embed parameterized SQL directly into TypeScript and double cross-compile it into front-end and back-end elements. (We use an ES5-Python-Postgres stack, but our compiler is designed to work with any back-end language and any SQL database.) We now get 10x more work done every day! Individual programmers write entire interactions and are not dependent on others to complete their day-to-day work, just like we did 30 years ago. We call it BATON, which stands for Back To the 90s, but it's not yet for sale. If this interests you, please get in touch: we're looking for more launching customers.
The good thing with ORMs is that they do a lot of magic for us. The bad thing with ORMs is that they do a lot of magic for us.
ORI is partly caused by the choices made in SQL towards the use of relational algebra and conventional storage technology. Addressing both might provide a further productivity boost and optimize system performance.