There is of course the `Kernel#send` method, which implies the model is messages being sent. It's not called `call`.
The fact it isn't invoked for regular method invocation is kinda indicative of Ruby _not_ being a pure message passing language, even if we like treating it that way.
It's definitely Kernel#send. Object defines no instance methods at all.
> Kernel.instance_methods(false).include?(:send)
=> true
> Object.instance_methods(false).include?(:send)
=> false
> Object.instance_methods(false)
=> []
That's a somewhat arcane implementation detail though. What about the meat of the discussion?
If I'm being uncharitable I think applying the term 'message passing' to Ruby is a bit of making something sound more sophisticated and elaborate than it is. They're method calls - it's pretty simple already and doesn't need a complex concept on top of that.
It’s a little tough to compare to an OO language because there are no classes, but all object to object communications are asynchronous messages.
This is the way I think about it as well, the more concise notion is ask don't tell. By don't tell I'm thinking of telling an object to change it's state directly. This distinction can be very, very subtle.
To me, it's the difference between pulling the strings on a puppet (method calling) vs placing a request to a colleague (messaging).
However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. I think the option to write in this style is really a byproduct of duck typing combined with a Ruby object's ability to arbitrarily and dynamically reconfigure its own dispatch table. If Matz really intended a message-passing style, then Object#send would've been split into Kernel#send and Object#receive, and there'd probably be a Message class rather than just using symbols.
Given the new shorthand of object.:name in 2.7 for object.method(:name) one could even argue that Matz is drifting Ruby back towards an early binding style. However I don't see myself using that syntax much outside of block parameters to Enumerable methods and the like.
Overall I think the stylistic options are a strength and we don't particularly need to resolve the dichotomy to write good Ruby.