It is a fair question, and the people asking it usually have scars to back it up. But listen closely to the complaints and they are almost never about mapping rows to types. They are usually about everything else the ORM does.
Let us make the argument properly, because it deserves it. ORMs hide the query, so you cannot see what runs against your database. They make performance opaque, so an N+1 or a missing index surfaces in production instead of in review. In the JPA world, they often put JPQL or a criteria API between you and the SQL you already know, and then abandon it the moment you need something it cannot express. And they couple your objects to a session lifecycle, which is where a whole genre of runtime errors comes from.
There is truth in all of those complaints. If that were the whole story, the answer would be simple: drop the ORM and write SQL by hand.
None of them is about mapping. Connecting a plain record to a table, binding a parameter safely, turning a result row into a typed value: nobody writes an angry post about that part. It is useful and quiet. The common theme is concealment: the query you cannot see, the state you cannot track, the lifecycle you have to remember. The objection to ORMs is really an objection to hiding.
That matters, because hiding is not intrinsic to mapping. You can have the ergonomics of an ORM without the concealment. Those two things got bundled together historically, but they do not have to be.
ST/ORM keeps the useful half and drops the resented half. It maps rows to plain values and keeps the mapping concise by convention, so you are not hand-writing result mapping or annotating every column. But the SQL stays in view. There is a type-safe DSL for the boring, high-volume queries, and real SQL templates for the queries where SQL should stay SQL, with type-checked column references and parameters bound automatically. There is no JPQL to learn and no proxy to outlive.
So the answer to "why shouldn't we use an ORM?" is: avoid the kind that hides your SQL, hides your state, and asks you to reason about a lifecycle you cannot see. That is a real position, and we agree with it. It is also the kind of ORM we chose not to build.