my $string       = "this is a string" x 300 . "xyz";

cmpthese(500000, {
    'index' => sub {
        my $res;
        $res = index($string, "xyz");
    },
    regex   => sub {
        my $res;
        $res = $string =~ /xyz/;
    },
});
[download]

         Rate regex index
regex 97087/s    --   -2%
index 98619/s    2%    --

most Perl hackers still pull out m//...

Ok, I agree that index is faster in some cases. However, I think there are good reasons for the behavior of most Perl hackers:

1. m// "scales" better in terms of uses. You can use it for the simplest things as well as for very complex things. It is practical and idiomatic. To me, that sounds like a description of Perl itself.
2. If you use it for your constant string to begin with and then you decide you need metacharacters, the change is smaller. Ok, this is a minor advantage, as the change wouldn't be that big anyway.
3. If you are using regular expressions elsewhere in the code, the code looks more consistent, and that makes it more readable.
4. Worring about the speed of index vs m// may be premature optimization. If you wanted the fastest possible solution you might not want to use Perl in the first place. Even if you want the fastest possible Perl implementation it is always better to make the code correct and readable first, and optimize the hot spots later.

I realize that some of this reasons (particularly the last one) agree with your argument for using for and push instead of map. I just wasn't sure that your assertion regarding index was correct, as my benchmarks had shown the opposite in the past. Now I see that it depends on the situation.

Regarding the readability of map vs for, I would say that a distinct advantage of map is that it documents the purpose of the loop right at the top (when used properly). As soon as you see the map keyword you'll know that you are building a list and you'll know where it is being stored; with for, you have to wait until you see the push to see the true purpose of the loop. Which approach is better depends on the intention of the coder, and I agree that the size of the block may be a factor to consider. The problem is that the exact line between map and for is blurry, partly a matter of style and personal preference.