Well off the top of my head...
1. There is no need to do this! That's a big reason.

2. This is an overly complex calling syntax that is non-standard versus Perl norms. In general coding confusion into the program is not a good idea. That is an opinion. But I think that tricky non-standard things should be avoided.

3. This would interfere with some Perl debugging features.
 $subname = sub{...blah..} is ref to an anyon sub. Consider:

sub whoami  { (caller(1))[3] };  #returns name of the sub that called 
+this sub
sub whowasi { (caller(2))[3] };  #returns name of the parent of the su
+b that called this sub
[download]

In the case of $subname, there is no "name". I sometimes use code like whowasi() for debugging to trace back to where some weirdo sub input came from. If you are proposing to put a large number of anon subs in a module, this kind of idea breaks.

Just because something is possible, doesn't mean that you should do it.

For me: no need, overly complex, non-standard is enough. As I mentioned above there are ways to regulate what sub names get "exported" from a module which is a subset of the names in the package symbol table. There are naming conventions for OO methods like (_xyx is private). All that is "good enough".