There are two distinct meanings mushed together under the "messaging" umbrella:

A. One way communication, aka events, goto. Very useful as an implementation concept, but generally a poor idea for structuring applications, as it makes local reasoning about code harder than necessary.

B. Polymorphism, aka closures. This is a very useful device for modularizing code, albeit, in practice, vastly overused. It also happens to trivially fall out from the concept of "first class function". To have first class functions, we need to be able to create them at any point in the program, thus we need some form of variable capture to allow value capture, which was named "closure", in the example below "function g closes over variable x". Furthermore, we need to be able to return the function value we just created and invoke it later, in the example below the invocation of q(4) actually invokes the closure of g over 3. Once we have first class functions, we can add any number of concrete syntactic sugar constructs [classes, vtables, etc, etc, etc].

   def f(x) = {
     def g(y) = {
       x + y
     }
     g
   }
   val q = f(3)
   q(4)

IMHO, the "misunderstanding of OOP" is strongly attributable to a propensity in OOP community for using ambiguous terminology to pretend it possesses some sort of silver bullet, instead of recognizing the rather elementary computation constructs obscured by said terminology. In some alternate universe, we'd use "events" and "closures", and there will be very little misunderstanding. "messaging" is a false friend between computer languages and real world experience.

In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.

That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).

Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous.

So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".