While you can write either flavor in most languages (even Elixir if you abuse ETS), concurrency's requirements for immutability and run-time support start becoming distinguishing factors.
Synchronous method calling as limited message passing; synchronous method calling as general message passing, and asynchronous message passing.
Java and C++ and most static class-oriented OO languages are in th first group.
Ruby and Smalltalk (and JS, which isn't, barring more recent developments, class oriented OO, bit is still OO) and some other dynamic OO languages are in the second group.
Elixir/Erlang are in the third group.
Message passing is inherently an imperative idiom (whether synchronous or not), even though it may show up in languages that are largely declarative rather than imperative outside of message handling.
Not really, “a limited echo of message passing” would have probably been more accurate than limited message passing: C++ and Java Ivor a form of OO inspired by Smalltalk-style message passing but are implemented in a way which provides something much more limited.
someBool ifTrue: [ "some block to execute" ].
Loops and such are also similar. Granted most of these things probably end up being implemented in native code on a practical level for performance, but conceptually it's a very small language. Most of the standard library and IDE is written in itself. Ruby definitely has a lot of flexibility, but it also has way more built-ins and much more separation between "interpreter code" and "user code"
I think this is what people are missing when they bring up the point that messages and method calls seem very similar. In a practical sense yes, but the smalltalk style message system is more about messages being a fundamental building block of the entire system.
While “if” doesn't work that way in Ruby, loops do (there is a for..in statement, but it's syntax sugar for a call to #each, and not idiomatic to use it anyway.) Python does a lot of that; putting loosely C-style syntax as sugar around method calls (which themselves support more general message passing patterns than Java-style method calls.)