For me, separation of concerns. ActiveRecord, by design, handles a lot of concepts including persistence, validation, callbacks etc. This means that while it is simple to use the actual code for ActiveRecord is complex making it harder to work with and change for the maintainers.
By breaking things down in to smaller objects which collaborate to achieve the same end result the code can become easier to think about. Now my object has this one responsibility and I put it together with other objects to build up my system.
As a practical example, with AR I can not save the model unless the validations pass. But I might have a situation where I want to skip a validation, that isn’t easy to do with AR. But if my persistence, model and validations are separate I can have different validation objects for each state I want to persist. It means I can use the same objects in different contexts.
For me contexts is the important part, in simple applications AR is a great choice. It is easy to use and everything is contained within one place, the model. But as an application grows you start to introduce different contexts and more edge cases. This is where having separation of concerns really helps provide flexibility without having to hack around the AR design.