this assumes that neither $string_or_number nor any of the elements of @strings_or_numbers are ever undef

It also makes other (corner case) assumptions. For example things get a bit dubious when the numbers (barewords) 1.4142135623730951, 1.4142135623730952 and 1.4142135623730953 (on a perl whose NV is double) are subjected to stringwise and numeric comparisons:

use warnings;

my $x = 1.4142135623730951;
my $y = 1.4142135623730952;
my $z = 1.4142135623730953;

print "$x $y $z\n";

$x == $y ? print "x and y are numerically equal\n"
         : print "x and y are numerically unequal\n";

"$x" eq "$y" ? print "x and y are stringwise equal\n"
             : print "x and y are stringwise unequal\n";

$z == $y ? print "z and y are numerically equal\n"
         : print "z and y are numerically unequal\n";

"$z" eq "$y" ? print "z and y are stringwise equal\n"
             : print "z and y are stringwise unequal\n";

__END__

Outputs:

1.4142135623731 1.4142135623731 1.4142135623731
x and y are numerically equal
x and y are stringwise equal
z and y are numerically unequal
z and y are stringwise equal
[download]

So it makes the assumption that this behaviour is as wanted - which, if you look closely, is rather unlikely.
Perhaps (not guaranteed) the first two results are as wanted - even though the two barewords are mathematically unequal they do convert to identical doubles and strings.

But the last 2 results are just bizarre, imo.
That perl should stringify two different NVs to the same string is rather pathetic - and it happens because perl by default stringifies doubles to only 14 decimal digits. (Update : make that 15, not 14 - the trailing zero for my example values was stripped.)
If, like in python, the default was 17 decimal digits (as some believe it should be) then the discrepancy of the last 2 results would not arise.
(We can, of course work around this stringification problem using sprintf, but that just makes it messy.)

BTW, the same problem arises with perls whose NVs are 'long double' or '__float128'.
Perl simply does not stringify floating point values to enough decimal digits.

Cheers,
Rob