Hmm.. that's true, but this:

    $n  =1;
    $ref = "n";
    $$ref = 2;
[download]

Gives us a dump that looks like so:

g  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 sym.pl:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const[IV 1] s ->4
-        <1> ex-rv2sv sKRM*/1 ->5
4           <#> gvsv[*n] s ->5
6     <;> nextstate(main 1 sym.pl:2) v ->7
9     <2> sassign vKS/2 ->a
7        <$> const[PV "n"] s ->8
-        <1> ex-rv2sv sKRM*/1 ->9
8           <#> gvsv[*ref] s ->9
a     <;> nextstate(main 1 sym.pl:3) v ->b
f     <2> sassign vKS/2 ->g
b        <$> const[IV 2] s ->c
e        <1> rv2sv sKRM*/1 ->f
d           <1> rv2sv sKM/DREFSV,1 ->e
c              <#> gv[*ref] s ->d
[download]

The difference doesn't appear to be large there, either. This time the switch is between ex-rv2sv / rv2sv and gvsv / gv. I don't have a copy of the perl source at hand, but I'd imagine the behavior is much the same as in method and method_named. The problems are similar, after all.

The point is, that little bit of indirection occurs in a place where things can go blooey with frightening ease. Imagine code that took the method name as a function parameter instead of looking it up in a statically-defined list. Yucko. Granted, Perl won't auto-vivify functions or clobber a function definition because of a typo, so this is less dangerous than using symrefs for lvalues, but the general mechanism can still be used to do some horribly ugly things.

Still, you've tipped the scale a bit further in the "less dangerous than flossing with a loaded shotgun" direction, so thanks for your time.