I think a lot of times people say “ORM” when they mean “Hibernate” or some other ORM implementation.
In your codebase, do you stick raw SQL all over the place and iterate over rows exclusively? Or instead, as a convenience, do you write helpers that map objects into SQL statements and map result rows into objects? If so, congratulations, you’re using an ORM. The concept of ORMs is not bad. It’s a logical thing to do. Some ORM _implementations_ have some very serious issues, but that does not make ORMs as a whole bad.
I'm not sure I'd consider query-builders to be ORMs. You do inevitably have a mapping from query resultset to list<obj>, so it does meet the name itself, but there's clearly a very large difference between "Hibernate" and query-builder, and if you don't want to use ORM to be the differentiating term calling out Hibernate and friends specifically, then let me know what you do wish to use. But as far as I know, colloquially and commonly, ORM refers to the former -- not the general act of having any mapping at all.
In your codebase, do you stick raw SQL all over the place and iterate over rows exclusively? Or instead, as a convenience, do you write helpers that map objects into SQL statements and map result rows into objects? If so, congratulations, you’re using an ORM. The concept of ORMs is not bad. It’s a logical thing to do. Some ORM _implementations_ have some very serious issues, but that does not make ORMs as a whole bad.