Sometimes methods don't fit neatly into a specific model object. They may cut across multiple model objects, or call out to external libraries for logging and metrics.

When this happens, you can either have model objects that know too much about their surrounding environment, or you can put the code somewhere else.

In Rails, that "somewhere else" is usually a controller. But that's messy because now your application's logic is spread between a controller and multiple model objects.

Interactors are a way to clean that up. It allows you to put all of the code to accomplish a use case into one well-named place.

Good programming is about managing complexity. In practice, interactors have served us very well in managing complexity.

(Note: I work on the same code-base as the author of the article.)

You can obviously build them wrong and end up with an anti-pattern but no, the Interactor pattern is all about managing how your objects communicate and building code units that are single business cases. In the OP's case, the Comment model shouldn't ever care about Mixpanel, or potentially emailing people that a new comment was posted, that logic can all go in an Interactor, where encapsulation and SRP is not invalidated.

Interactors let models handle only what they need to know, and help minimize the coupling between these models. Trying to follow how a feature is implemented in a "typical Rails app" can be a nightmare of View -> Controller -> Model -> lib -> Model -> etc. With this pattern, as long as the interactors are well named, an entire feature can be encapsulated in one object.