I call that post-OOP. The outcome might even be very, very similar to what you might have implemented as an OOP believer, but the assessment has flipped: instead of assuming yourself "did I use enough OOPisms" you ask yourself "could it be better with less?"

I'm not gonna argue against OOP in general here, but in the context of ORMs, some of the most important characteristics of OOP (encapsulation and inheritance, especially) are the source of many anti-patterns.

Keeping methods that operate on data together with the data is the biggest problem with the Active Record pattern, and it's good that some new ORMs (like Ecto) are inspiring others to try other alternatives. Those alternatives invariably eschew the exaggerated use of method/data coupling and code-sharing via inheritance/mixins, among other things. They are either functional or procedural.

Not to mention that a lot of OOP-heavy codebases are already replacing a lot of OOP-heavy ORM code with procedural (Services) or functional-inspired ("Railway Oriented Programming", Trailblazer operations).

Sure, there are still classes being used. But I don't think it's fair to call "just using classes" as really as OOP, when they're used as structs, and especially in languages that make class usage mandatory.

I dunno I've been using rails for over a decade, its lovely.

I never said otherwise. “Lovely” and “the ORM is free of issues” is orthogonal. The issues are why there’s a lot of different alternative ways of writing domain logic in Rails.