I find it very easy to understand. In general, that should trump issues of speed, memory, or namespace.

Interesting justifiction. Personally, I prefer solutions that are:

1. Clean.

   Don't create persistent, named temporaries to clutter, conflict and confuse the purpose of the code.

2. Clear.

   Don't introduce unnecessary (and counterproductive) levels of indirection in the name of premature optimisation (avoiding copies).

   It is more expensive to takes references then dereference those references; than to make copies of simple, small scalar values:

   ($a,$b,$c,$d,$e) = 1 .. 5; 
   cmpthese -1,{
       a=>q[ my @a = ($a,$b,$c,$d,$e); ++$_ for @a;],
       b=>q[my @a = \($a,$b,$c,$d,$e); ++$$_ for @a; ] 
   };;
         Rate    b    a
   b 525790/s   -- -23%
   a 685872/s  30%   --
   [download]

3. Concise.

   The goal of this snippet if to cross-compare a few variables with the only interest being a single boolean truth.

   Spreading that across half a dozen lines, adding named temporaries to the mix; adding a module, a callback and nested loops; and obscure indirections to derive a simple boolean does the very opposite of making things easy to understand.

4. Simple.

   Simple means when the algorithm calls for:

   if( <some condition> ) {
      ## do somthing
   }
   [download]

   the implementation (code) should reflect that. Not detract from the algorithm by introducing unneeded complexity.

5. Efficient.

   looping to perform all 15 comparisons when the first or the second can resolve the boolean condition is just flagrant waste.