The article favors Rails concerns to isolate both the AR-relation, as well as the bahavior. In some cases this can be a good solution.

Concerns can be shared between models, that could be good or problematic, depending on the case.

For "real" business logic, a separate modeling is a better approach. (e.g. compute interest on a given account over a period of time).

what the author refers to as POROs, I'd say could be modeled as Ruby modules, not classes - they don't keep state.

Rating::Processor.run(rating_record)

Timeline::Activities.add_for_rating(rating_record)