First, Ben noted that callback functions are a type of closure.
Right. The app I am developing in my work is an intranet application that you access from a web browser. The current version is written as PHP pages which are backed by a database. You can think of the whole thing as a database application if you like, which it basically is, really. Some of the information needs to be displayed on-screen in a tree-like structure - much like the directory listing in Windows' File Explorer. Without getting into an argument about OO, we designed a Node object for representing a node. Each Node knows it's parent node, and has a list of it's children nodes. It also has a piece of arbitrary data which represents what is actually "at" that node. Thus a Tree is a Node with children Nodes, any of which can have children, etc etc. A simple recursive function is sufficient to print it using pre-order traversal, which display things as we want. But how to get something printable out of the opaque data?
In a pure OO world, the data could simply be defined as an object which responds to a suitable method. Well, while PHP's object infrastructure would support this, the rest of our app isn't pure written OO-style. Besides, these Trees are going to be created, displayed and then discarded in the same page. So we decided on a callback function: the display function takes as one of its parameters the function name which it calls for every node. The callback function is given the opaque data of the node in question as well as some optional extra information (to eliminate global variables) - all it has to do is output what is to be displayed.
Simple, clear and elegant.
FWIW, PHP also supports creating functions on-the-fly for this kind of thing, although it's a bit clunky and only works because the whole language parser is available at runtime...
Wade.