In my opinion ... and it is “my opinion” only ... ORMs turn out to be a colossal (a) waste of time, and (b) source of complexity and maintenance headaches.   And yes, I have dealt with many very-substantial applications that did it both ways.

Instead of elaborating on these matters, though, my core objection to them is really one of philosophy.   The foundational argument behind these classes is the premise that “a database table === an application object.”   This is very rarely the case, IMHO.   Instead, a set of database tables provides the data source(s) for “a proper ‘application object,’” and the object itself consists of much more than simply a programmatic expression of a 1->1 and/or a 1->M relationship.   In a real-world sized application, many related objects might draw information from the same table, yet the structural strength and integrity of each of these objects is, yet again “IMHO,” considerably weakened(!) by spinning-off parts of it to a “third-party class” which represents any single table and which seeks to express anything anywhere that has anything to do with this particular table.   Note that you can commit this error with or without DBIx, but DBIx and its kin make such errors (IMHO) considerably easier to commit.   A program-object is not necessarily a data-object, and a pure-data-access object often is not useful and (IMHO!) does not belong.

My career experience consists mostly of dealing with now-recalcitrant applications, many of them built over the last five to ten years, which at the time were very lavishly built but which now are collapsing under their own baroque weight.   (As such, I do not fear running out of a job anytime soon ...)   These monsters are being scrapped, decommissioned, or “in-sourced,” left and right now, and one of the key reasons for this is their “bespoke” complexity.   The system must be changed in some deep way, so the logic pertaining to what it does now must be cleanly isolated, extricated, and replaced ... but there is simply so much coupling within the system, so many source-code modules (and configuration files) that must be simultaneously understood and touched, that the software-machine becomes unmaintainable.   Since data (structure and access) touches literally everything everywhere, it becomes the straw.