It’s not merely a “lisp worldview”. Evaluating the function as an object separate from evaluating the arguments, and then applying the function to the arguments, is a property of nearly all languages with first-class functions. (This excludes many traditional static OOP languages like Java and most of C++. C++ and Java have made steps in the direction of first-class functions with limited lambda expressions and () overloading, but e.g. new methods cannot be added to C++ functor objects after they are created.) Take a step back and realize that you are insisting that everyone else is confused because your unfamiliarity with first-class functions made it difficult to communicate with you.
As @jeff.bezanson said in the other thread, even if you have a kind of “ADL object”, you would still need a global namespace of such objects, and furthermore having a method become applicable because its signature narrowed (and thus entered a new type’s namespace) is totally different from the subtyping model of dispatch. I don’t think you grasped the implications of these remarks, especially the latter. What you are suggesting is a complete upheaval in how the language works, not merely an incremental change (excluding add-on packages that emulate ADL by implementing their own lookup tables).
It may be interesting to think about as an academic exercise, but I think you’ve confused people understanding how to better explain the difference between Julia’s dispatch and the ADL you are used to with agreeing that there is something wrong with Julia’s approach (which is common to all all other dynamic multiple-dispatch languages AFAIK) that we need to plan to “fix” in Julia 2.0. Also realize that Julia 2.0 is probably many years away at this point, and planning complete language upheavals (as opposed to new features, optimizer improvements, static compilation, better multi-threading, etcetera) is very far down on everyone’s priority list.