|Perl: the Markov chain saw|
While closures may look like a poor man's object, I think the reverse is closer to the case.
Using only closures you can build an OO system, with what looks like an OO syntax. I believe that Smalltalk's OO system works like this. Definitely Lisp's CLOS does.
By making classes multiply like rabbits, you can mechanically translate code involving closures into code involving objects. But I am having trouble seeing how you could make those closures integrate into an OO language and look like they do in a functional language. (Perhaps my imagination is not very good though.)
Anyways what I find that closures do which OO does not do so well is allow you to "inline" logic that in OO programming would involve having to create classes and methods just to do a small thing, privately, within a function.
For instance take the DESTROY method. Perl offers a way to use it in an OO context. If I want to set up some sort of finalizing action on something, I can always create a class, with a constructor and a DESTROY method. Each different kind of action requires a whole class. Ick.
However if you look at my ReleaseAction, it allows you to do the same thing, with the action defined by a closure. Now you can, within a small function, define any useful DESTROY behaviour that you need, without having to create a class for it. That allows you to put the definition of the behaviour where it is most maintainable, right where you need it. What you are doing isn't fundamentally different, but you think about it more compactly.
Let me step back, and explain that differently, since in trying to say it I think I figured out a better way to understand it.
Conceptually an object is the concept of a thing with multiple customized behaviours, and with a defined structure for building a system with lots of objects, some of which share some of the same (or similar) behaviours.
Conceptually a closure is the concept of a thing with a customized behaviour.
It turns out that closures are general enough to allow you to build arbitrary objects. They may not look like they can do that, but they can.
However if what you need is a customized behaviour, objects have a ton of baggage that you cannot shed. This forces you to structure your code in a less natural manner for the ideas expressed, and that overhead limits how you tend to think about problems, forces unnecessary duplication of code, etc, etc. As a result there are solutions that are quite natural using closures which people do not naturally build without them. (And if they tried to build those solutions without closures, the result would be an order of magnitude less efficient, but I digress.)