Alright, I must apologize, I made an error while trying to use your benchmark. I am sorry about that and about what I said about your tests.

try downloading this and running it on your laptop(and post the results if you dare!)

No need to be very daring, I can recognize a mistake of mine when that occurs. I admit that I was wrong on this point.

How d'you expect code that is eval'd from a string, to see a lexical array?

Of course, code that is eval'd from a string can see a lexical array. Just an example:

use strict;
use warnings;

my $c = "foo";
my $d = "print q{$c}, q{\n}";
eval ($d); # print "foo"

my @f = 1..10;
process_f();

sub process_f {
     my $g = 'print "$_ " for @f; print "\n";';
    eval ($g);
}

my $h = 'my $i = sub { print map {$_ *= 2; "$_ ";} @f; print "\n" }; $
+i->();';
eval ($h);
[download]

Here, the problem occurs only because the string is passed to a module function in a separate file, so that the lexical is neither passed as an argument, nor seen as a global. Which is by the way the reason why I don't like using the string version for the Benchmark module and almost never use it. And this is why I made the silly mistake, almost never using this form.

map is faster than for. Just like I said.

I don't think this is true. I've tried your code a dozen times on three different version of Perl, for was almost always faster than map by a very thin margin. As a final test, I increased the number of iterations to 50,000 on Perl 5.18/Windows 7:

use strict;
use warnings;
use Benchmark;

our @array2 = 1 .. 1000;
timethese 50000, {
    "idiomatic" => q[     $_ +=2 for @array2; ],
    "map"       => q[ map $_ +=2,    @array2; ],
};
[download]

Benchmark: timing 50000 iterations of idiomatic, map...
 idiomatic:  3 wallclock secs ( 2.87 usr +  0.00 sys =  2.87 CPU) @ 17
+421.60/s (
n=50000)
       map:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 16
+436.55/s (
n=50000)

Benchmark: timing 50000 iterations of idiomatic, map...
 idiomatic:  3 wallclock secs ( 2.87 usr +  0.00 sys =  2.87 CPU) @ 17
+421.60/s (
n=50000)
       map:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 16
+436.55/s (
n=50000)

Benchmark: timing 50000 iterations of idiomatic, map...
 idiomatic:  3 wallclock secs ( 2.86 usr +  0.00 sys =  2.86 CPU) @ 17
+513.13/s (
n=50000)
       map:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 16
+436.55/s (
n=50000)

Benchmark: timing 50000 iterations of idiomatic, map...
 idiomatic:  3 wallclock secs ( 2.87 usr +  0.00 sys =  2.87 CPU) @ 17
+415.53/s (
n=50000)
       map:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 16
+436.55/s (
n=50000)

Benchmark: timing 50000 iterations of idiomatic, map...
 idiomatic:  3 wallclock secs ( 2.87 usr +  0.00 sys =  2.87 CPU) @ 17
+421.60/s (
n=50000)
       map:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 16
+436.55/s (
n=50000)
[download]

The results are very consistent throughout and it certainly cannot be said that map is faster than for. At best, they are more or less equivalent. But my initial point has never been about performance anyway, but only to suggest a possible explanation for the OP's original question.

Again, I did not want to have a debate with you on this subject in the first place, because I think we were agreeing on most things. And I want to reiterate that I am sorry that I made an error leading me to believe and to say wrongly that your test was wrong.