|The stupid question is the question not asked|
I completely agree with you, with one caveat. The abstraction has to be well designed and well optimised. Perl's regex engine is a great example of abstraction done well.
A counter example is trees & tries. These are immensely useful structures for many purposes, and there are quite a few flavours of both on CPAN. But, for the most part, they are almost useless for anything but experimentation and the most trivial of applications. They are, mostly, based upon using hashes to construct the trees, with the result that the are slow, clumsy and hugely memory hungry.
Basing my opinion only upon the little I have read here and elsewhere, not yet having succeeded in laying my hands on a copy of HOP, the main problem with the style of coding it explores is that Perl isn't sufficiently tuned for it. To see the problem, take a look at this HOP-like implementation and constrast it (performance-wise) with procedural implementation of solutions to the same problem.
That's not to say there isn't a lot to be learnt from the concepts explored in HOP, just that the costs of sub calls, coderefs and recursion in Perl 5 do not lend themselves to this type of programming where performance is a consideration.
And not all Perl apps are web applications, DB or IO bound, or otherwise "interactive" where performance can be measured in response times.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.