Consider that the call-site in Ruby in the general case does not have any guarantees about how the recipient of a message will act on the message.
As an implementer, as you of course know from the amazing optimizations Truffle Ruby does, there are certainly lots of special cases where you can aggressively decide from an implementation point of view that you know how the recipient will act. So in practical terms a lot of code that uses systems that conceptually can do message passing will in practice in many - or even most - cases act exactly the same as a pure method-calling system.
But the conceptual difference is that in a message passing system, you can not do so for the general case before execution starts, because there is the chance that the treatment of messages change dynamically at runtime. E.g. the "fun" case of a program that eval()'s a user supplied string that redefines a method, to take the extreme case. "pry" and "irb" are good examples...
To me at least, message passing and "extreme late-binding of all things" relate to systems that conceptually allow deferring the decision of which piece of code will get called until the moment a message is passed, whether or not a specific instance actually makes use of that flexibility, while a "method call" implies that you can know in the general case by static analysis which method will be invoked, or at the very least which of a small, constrained set of methods will be invoked.
Of course you can always emulate one with the other, so the boundaries gets fuzzy.
EDIT: Put another way: You can implement message passing in any system by defining a send(object, ... args) function that implements dynamic lookup and allows the program to modify the lookup at runtime. One step up is to implement a "send(...args)" method on a class in a C++/Java style OO system. So any system can have message passing. But the difference in whether or not we consider a system message passing is largely a question of whether or not the system provides syntactic sugar to make that easy and whether or not it is considered idiomatic use.
Re: method_missing, I supoose it's not as easy to understand as I thought, which is to say if I understood it better, I could explain it better. The best I can do is this...
1. A typical method call in Java means "I pass a message (args) to a method on some object, and block until I get a response", which usually means building of up stack of blocking calls waiting for a response". The message passing is sending the message, which in Java is tightly coupled to receiving the response.
2. In Erlang, you might have a process (think of it as an object for this example [1]), that sends a message to another process. The sending process doesn't need to wait for a response. Erlang does have function calls that feel pretty much exactly like method calls in Java, and then there is message passing between processes, and that separation makes the differences more clear to me, which is not to say I understand things correctly.
3. method_missing in Ruby is kind of like sending a letter in the mail to Santa Clause. There is no physical address for Santa (aka an undefinded function), but someone at the post office looks at the intended destination (SantaClause.mailing_address) of the North Pole and message itself ("I have been good, and want a Nitendo Swith for Xmas"), and determines how to respond (method_missing) to the message.
I do not know if this explanation is any good, so please be kind :) Doing my best!
I wrote a PhD on method_missing, and I still don’t really see how Ruby is message passing rather than just normal method calls.