Optimize for your users above all else. Yes, even above developer experience. If that means optimize for performance, you optimize for performance.
The only thing that matters is what your users feel when using your product. Everything else is a waste of time. OOP, FP, language choice, it's all just fluff.
5. Abstracts away db fully if you want, not use db specific features
6. Lazy loading as an encapsulation promoting mechanism
None of these things are especially hard and I’d argue query builders that compose and some other tools deal with these points in a simpler and more efficient manner. Migrations in most cases require careful consideration with multiple steps. Simple cases are simple without ORM.
I’m pretty confident most users of ORM are dealing with problems inflicted by ORM behavior, not db. The biggest infliction is natural push towards single-entity logic that is prevalent in OOP and ORM design.
Business logic ran fine on ancient mainframes. It can run fine on Raspberry Pis.
CRUD is super easy. It's also not super resource intensive.
I know that's the path that led us all down into Java OOP / start menu is a react native component, but it is actually true.
ORM adds a convenience layer. It also adds some decent protection against SQL injects OOTB and other dev comforts.
Is that trade off worth it? Probably not. But sometimes it's the best tool for the job