Clarity of intent.

• The first indicates (to me) that you are doing a whole string comparison. There is only one thing that the eq operation is able to do.
• The regexp opens the possibility that there is something more complex happening. Even in this simple case, I still would need to switch languages to verify that there was nothing else going on in the statement.

Admittedly, in this case, it is not a very complex regexp, so it probably does not make much of a difference. If I am doing a full string comparison, I reach for eq. If I am matching a pattern, I reach for a regexp. It seems to me that any cue that you can give to the future-you reading your code is a good thing.

Update: As far as what to do once it gets a number of comparisons, refactor the comparisons out into a subroutine with a descriptive name and call it.

The following statement takes a bit to digest:

( $var eq 'a' || $var eq 'b' || $var eq 'c' || $var eq 'd' )

where this replacement, at least to me, is much clearer:

( isAnAllowedCharacter( $var ) )

This also allows you to change the definition of what a valid character (or whatever you are testing for) is without changing the code that is performing the test:

sub isAnAllowedCharacter {
    my $testee = shift;

    ( $testee eq 'a' || ... )

    # or perhaps

    %valid_characters = map { $_ => 1 } ( 'a' .. 'd' );
    $valid_characters{ $testee };

    # or even perhaps
    my $validation_service = Remote::Validation::Service->new(...);
    $validation_service->isValid( $testee );
}
[download]

Update 2: Missed this one before:

This simplified example shows only two elements to compare but if there were more the expression could get quite long.

It seems to me that a regexp with many strings can be just as unreadable as a series of $var eq '...' comparisons. Whitespace (and /x on the regexp) can make a world of difference.