In short, (in Perl at least) closure is faster than object due to less dereferencing overhead but could be slower due to larger memory requirement? (In the test, the edge of closure over object was diminishing and even reversed when the tasks were getting more "heavy-duty.")

No, larger just means larger (unless you get so large you swap). Heavy use of closures would make me at least consider memory usage.

How would you characterize and procedurize a "functional design process" (if there is such a thing). Like a user manual on Design: the Functional (or Closure) Way.

I read two distinct thoughts in the rest of your question. Design by documentation and programming style. The programming style question is likely best answered by pointing you to Why I like functional programming. My own coding style is largely procedural for the smaller cases, object oriented for the larger picture with plenty of functional goodness. Most of my exposure to logical programming comes from SQL and XSLT (which I adore). The point is that for common, every day programming there is a lot to be gained by being flexible and drawing from many disciplines.

It lets me get my work done and done right.

As for programming by documentation, I'm playing with that right now. For the project I'm on I've been writing the documentation for processes that the code implements and then just like mortar, filling actual code in after the fact. So far its a dream. I think other people call this ``Design by Contract'' but I couldn't swear to that. In fact, there's a module Class::Contract which purports to help you write code that way (though if you read just the documentation you won't understand DoC).