It avoids micromanaging.
If I tell you to stop in an OO way I haven't called your stop procedure, or your stop function, or your stop method. When I send that stop message I've raised a stop event. One that you are free to handle or not. You don't even have to respond. Now sure, you might use a stop method to handle that, but that's your problem.
This avoids micromanaging because I don't have to deal with how you respond to being told to stop. I don't have to think, "OK I told him to stop, now what's he going to do? If he ignores me then I'll do this, if he has a problem then I'll do that, if he stops then I'll do this next thing". No, that's micromanaging. If anything needs to be told what happened when you got told to stop it's better to let you decide who to tell. It gives me fewer things to think about. It gives you more freedom to control your stop response.
This keeps a very low form of coupling between objects. Lower even than typical1 functional programming. Functional programming does composition beautifully. Pure functions make reasoning simple. But it locks you down to sending the response back to the caller. It has nowhere else to go. That couples caller to callee. Messages, however, can go where they've been configured to go without worrying what becomes of them. It's not as straightforward but it's another detail avoided.
Another benefit is minimizing data movement. Functional programming has been called "data in, data out". OOP wraps data in a "message in, message out" system. The messages can be very lightweight compared to the data.
I'm contrasting OOP with Functional here but that shouldn't be taken to mean you exclusively use one or the other. Many of functional programmings principles can be used while using OOP. Prefer immutable objects. Be disciplined with side effects. Etc.
OOP messaging is a powerful way to model. It inherently respects encapsulation. I don't look inside you. I don't ask you about your privates. I tell you what I want done and you decide what, if anything, to do about it. Once I tell you, I don't have to hover over you and manage what you do. I just let you do it. Whatever it is. If I ever need to know more I'm sure someone will tell me.
Messaging is sometimes implemented by using methods as the messages but that's just one way to do it. It could be text messages, packets, tweets, emails, etc. The methods are not what makes it OOP. It's how you use them.
Here's the rub. Just because you're using an “OOP language” that has methods doesn't mean every method is a genuine OOP message. No language perfectly enforces this. Your programming team has to enforce this. Depending on the design, a method may conform to requirements of a OOP message. If you're lucky your core packages will follow this well. I've never worked on a project where OOP was 100% enforced or a functional project where everything was pure. But the better projects will find some way to at least signal clearly where the ideals are followed and where they have been compromised. This is important because it impacts the readability of the code. It's good to quickly know if you're looking at a true OOP message, a pure function, or some other monster.
Joel has blessed us with this awesome comment:
1. Regarding Functional Programming only returning to the caller, I would suggest looking into the technique continuation passing style combined with tail call optimization. "When you're done here, talk to this other guy. I will show myself out." – Joel Harmon
This is all true. But if the caller is saying "talk to this other guy" the caller is still dealing with knowing where to send the response. To put functional programming coupling on par with OOP (that configures output ports in constructors) pass "this other guy" into the enclosing scope of a closure. That way the caller neither knows nor cares where the result goes.