Including the /o-modifier, the list now has 3 language features that seemed a nice idea at first, but aren't really usable now.

I've read the thread you quoted and I'm obviously missing something because in my experience /o works exactly as it should:

use Benchmark;

my @words = map { chomp; $_ } (<DATA>);

my $alpha = '[a-zA-Z]';
my $alnum = '[a-zA-Z0-9]';

timethese(2000, {
   'Without /o' => \&testsub,
   'With /o'    => \&testsubo,
});



sub testsub {
  my $count = 0;

  foreach (@words) {
    $count++ if(/^$alpha$alnum+$/);
  }
  return $count;
}


sub testsubo {
  my $count = 0;

  foreach (@words) {
    $count++ if(/^$alpha$alnum+$/o);
  }
  return $count;
}

__DATA__
1500
words
one 
per 
line
[download]

Which on my system shows that with /o is three times faster than without.

Using variables to give meaningful names to chunks of a regex is very useful for improving the readability, maintainability and reusability of the code. Without /o it would be inefficient. What is it about /o that makes it "not really usable"?

Update: I added this to the test script:

my $qr    = qr/^$alpha$alnum+$/;

[snip]

sub testsubqr {
  my $count = 0;

  foreach (@words) {
    $count++ if(/$qr/);
  }
  return $count;
}

sub testsubqro {
  my $count = 0;

  foreach (@words) {
    $count++ if(/$qr/o);
  }
  return $count;
}
[download]

The qr// approach seems to be about 20% slower than /o and qr// + /o seems to be about the same as /o alone.