Both those forms are more complex than they need be:

$h{test} = sub{ print 'hi' };;
$h{test}();;

$p = \%h;;
$p->{test}();;
hi
[download]

Indeed.

However, there's a bit of information I haven't ('til now) divulged: In (AFAIR) both cases, despite the extensive use perl, the average perl 'reading age' was extremely low - typified by the lack ('til I introduced them) of dispatch tables anywhere (in matter of fact, the almost complete absence of other than the most simple of lookup tables) - I even encountered hashes keyed on sequential integers !!

Having introduced them [dispatch tables] and using calls of the form you exemplify, the code was considered unreadable by virtue of the implication of the use of parentheses.

However, they were eventually to adopt the structure - the final persuasive factor was the use of the form &{ ... }(...), which, they considered, would facilitate the readability of the code - since the fact that a call was being made (via a dispatch table) became explicit/obvious ... certainly to the reader of low perl 'reading age'.

A user level that continues to overstate my experience :-))

Generally speaking, I've preferred teaching perl developers a higher level of understanding to catering to lower levels. And, honestly, I find $foo->() eminently more readable than &{ $foo }() anyway.

Of course, the problem I've had with my approach has been getting said developers to want to learn more... which generally tells me how much I want them to continue to work on the code or not. If I had any say in who worked on the perl code, there'd be much higher turnover thus far. The lack of desire to learn, nay, the desire not to learn, would be a huge factor in this.