I feel that you may be missing the point. Let's say you are writing an interpreter for a language with closures and have to come up with an exact specification of how code using closures should run. Well, language designers need to guarantee reasonable, consistent behavior when a programmer passes functions around - namely, if those functions have free variables, how should those free variables be resolved? It so happens that there is a reasonable, consistent, way to implement function passing, and it involves creating this notion of a closure, which is executable code + some data (the environment) that you use to resolve any free variables within the executable code, if need be. It all boils down to a construct that language designers came up with to formally describe what happens when you pass functions into other functions.

Ask yourself - does Perl really need its own personalized definition of a closure? Why not use the one that's already in use in the PL community?