|Do you know where your variables are?|
If (when) this code stops working because of changes in perl, there will be a bug in the library. And this bug will be fixed (in a single place).
That is one of the most convoluted pieces of non-reasoning I've seen in a while.
Firstly, assuming that grep will (or even might) suddenly change in a breaking and completely illogical way is like allowing for the possibility that the Sun might rise in the West tomorrow. A theoretical possibility, but distinctly unlikely.
And even if grep did change; basing the correctness of your program on taking the statement that "The order of elements in the returned list is the same as in LIST.", as a guarantee, rather than just a statement of current reality, is naive in the extreme. What would you do if the author(s) decided "if its good enough for Perl, its good enough for us"? Sue.
I won't have to go through all my code and find all appearances of this code and fix it. I'd write my own function ...
The logic of putting common code in a subroutine -- the DRY principle -- is sound; but just as easily addressed by wrapping your posted code in a subroutine as it is by using a module.
Using List::MoreUtils::uniq() is a perfectly valid choice for any of several reasons, but on the basis of some inferred guarantee, isn't one of them.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.