So, instead of writing the method inside the class hierarchy, it is written outside and a receiver variable is used to signify to which class the method belongs. I guess this approach is a little bit more liberating, but it doesn't address the issues that I have with languages that implement strictly classical OOP (e.g., Java, C#, Haxe). In these languages, all code must be in a class, and further more, all data must be bound the code in the form of object properties. This why OOP produces big balls of mud; normal people (and computers) place the code over here, the data over there, and the program applies the code (as functions or procedures) to the data (as primitives, structs, objects, tuples, or other "dumb" things).
Still, the semantic notion of an object that can "have" properties and methods is useful. Personally, I prefer the approach to object-oriented programming that the Nim language takes. In Nim, the object data type resembles a struct like you have in C, but it is a little more sophisticated because a object in Nim can be extended hierarchically like a class in Java or C# can. However, in Nim, the object is just a data structure. There are no classes that have methods like there are in C# or Java. Methods are defined at the global scope of the module as ordinary procedures whose first argument is an object. Nim also provides the Universal Function Call Syntax; if there is a function f that takes two arguments a and b, then the syntax f(a, b) is equivalent to a.f(b). By providing hierarchies of objects but not classes, and by implementing what is semantically a method as syntactically an ordinary procedure, object-oriented programming can be done within a procedural paradigm. Go also does something similar to Nim by using receiver variables because it doesn't have UFCS, but I think this is not as elegant.