I think saying "the binding happens much later" in 2019 is unnecessarily hard to understand. The binder in Unix has always been called a "linker"; the term "binder" was used in a bunch of PARC systems and consequently in Oberon, but since Unix-influenced systems (and I think DEC-influenced systems like CP/M) called it a "linker", the verb "link" has entirely supplanted the verb "bind" for this purpose, about 30 years ago, except when people are repeating the phrase "late binding" or "late-bound" without understanding what it means.

So I'll explain what it means here, because it took me a lot of years to understand that "late binding" was a specific concrete concept rather than a vague generality.

What we're talking about when we say "binding" or "linking" is the process of associating a reference — typically to a function that's being called, though occasionally to a global variable or something — with a particular referent, such as a particular chunk of executable code. When we say that some "binding" is happening "late", what we mean is that this linking is happening at run-time — at the time of the actual call, not even at program startup time, as with ld.so. Doing the linking (or "binding", as some people called it 40 years ago) at call time means that the same function call can invoke a different function every time you call it.

Of course, that's what method calls in languages like JS, Lua, or Python do, as well as function calls in languages like Scheme, JS, Lua, or Python. By contrast, calls to C++ or Golang methods are compiled into machine-code calls to particular machine-code functions, unless the methods are virtual or via an interface, respectively, and it's the linker that links (or "binds") these calls to their callees. (Unless they're inlined, blah blah.)

This, of course, gives you immense flexibility, at the expense of some performance and predictability.

You're right to distinguish message passing from late binding, as message passing is more general.