In the specific example you benchmarked, comparing the two versions side by side devoid of the benchmark code, with some unnecessary punctuation removed and a few extra spaces for clarity (this is not a criticism of your preferences!) you get this:

sub {
    my %hash;
    my $reversed_data = reverse $data;
    $hash{ reverse $2 } = reverse $1
        while $reversed_data =~ /\s*([^=]+?)\s*=\s*(\w+)/g;
}

sub {
    my %hash;
    my $data = $data;
    $hash{ $1 } = $2
        while $data =~ s/\s*(\w+)\s*=\s*([^=]+)$//g;
}
[download]

The extra complexity amounts to 3 uses of the keyword reverse, and a longer variable name. The structure of the code is otherwise identical.

My question really is, is that "extra complexity" so onerous as to amount to a maintenance problem?

Conversely, whilst the original application's use of the subroutine in question may not greatly benefit from the optimisation, the next application that uses it could. It might call that sub in an inner loop and that 4.5x to 5x greater performance (on my machine) could be significant.

More importantly, if the efficient version becomes the 'standard' way of implementing parsing named parameters, and is used universally, rather than alternating between the optimal and non-optimal versions on a case by case basis, then the optimal version will become 'normal' and what, if any, potential for a maintenance problem may exists as a result of the "extra complexity", disappears because of familiarity.

I guess I am looking for the balance between consistancy in the face of future need, and simplicity.