It seems to have an effect to me...I also tried using a few other constructs...

timethese(-70, {
  and => 'my $m=0; for(@nums){if ($_ and $_>2) {$m++}}',
  or => 'my $f=0; for(@nums){if (($_||0)>2) {$f++}}',
  def => 'my $n=0; for(@nums){if (defined $_ and $_>2) {$n++}}',
  base => 'my $q=0; for(@nums){if ($_>2) {$q++}}'
});

This produced:
Benchmark: running and, base, def, or, each for at least 45 CPU second
+s...
       and: 49 wallclock secs (47.71 usr +  0.05 sys = 47.76 CPU) @ 60
+77.60/s (n=290266)
      base: 44 wallclock secs (44.82 usr +  0.18 sys = 45.00 CPU) @ 62
+05.20/s (n=279234)
       def: 47 wallclock secs (44.96 usr +  0.04 sys = 45.00 CPU) @ 60
+34.82/s (n=271567)
        or: 45 wallclock secs (45.00 usr +  0.02 sys = 45.02 CPU) @ 60
+34.41/s (n=271669)
[download]

This produced the results I generally expected...barreling along without tests allows us to go slightly faster. If you test more things you get even slower. However suppressing undefined warnings is often not good because undef is sometimes a 'this call didn't work' value or it is an indication of lack of defaults. For example in parameters to a cgi script it is better if you need to explicitly specify what you want where nothing is specifed (forcing you to think about what you do want).