Well, I dont really count as a Guru. But I'll give you as many reasons for why this type of thing is a bad idea, and frankly usually overkill to accomplish your task.

1. Your code will not run under strict. Strict will catch and prevent at compile time about 90% (if not more) of commonly made bugs. It will catch typos, it will catch accidentally using symbolic refs, it will catch awhole host of things that will not raise an exception otherwise, but will cause you hours of frustrating debugging. (If this hasnt happened to you yet its because you arent writing complicated enough programs.)
2. Symrefs are _only_ useful for accessing global variables (also known as dynamic variables.) Globals are dangerous. They promote action at a distance which can be very difficult to debug, and extend. Programs with a large reliance on dynamic variables tend to be fragile and easily breakable. Add to all of this, accessing a dynamic is about 10% slower than a lexical (or so the Camel says)
3. Very very occasionally using symrefs is a necessary evil. Especially in the case of autmatically generated subroutines. However when they must used then their presence and use is normally advertised in big letters "HEY IM USING SYMREFS, DONT GET CONFUSED" by doing the following:

   { #anonymous block to establish a limited lexical scope
     no strict 'refs';   # yes yes its evil, but i have no choice
     for my $sub (qw(foo bar baz)) {
       *$sub =sub { #insert a new subroutine into the appropriate glob us
   +ing symrefs
          # ...
       };
     }
     # All done with our symrefs now, normality has returned.
   }
   [download]

   Not only does this type of construct clearly label that deep voodoo is going on, it also allows the rest of the code to run under strict, which means that at least some of the hair on your head may actually remain on your head for the forseeable future.
4. There are more powerful ways to accomplish the same task. Learning and understanding them will improve your overall programming skills far more than playing games with something that can bite you and you dont really understand (namely symbol tables). (_{Please dont be offended by this statement. Your very post makes it clear you dont fully understand symbol tables and what can happen if you misuse them}) Consider your example could be easily rewritten to be

     use strict;
     use warnings; 
     #Now all I have to worry about is bad logic, not silly mistakes.
   
     my %things;  # hey its lexically scoped, nobody is going to step on 
   +this by accident.
     $things{wonderful}="A good Thing to behold";
     my @var=(qw(wonder ful)); # more lexicals...
     my $join_var=join("",@var);
     my $perlmonks = $things{$join_var} || die "Sorry, unknown thing '$jo
   +in_var'"
   
     #In this sample $perlmonks is equal to 
     #"A good Thing to Behold";
   [download]

   Which is much easier to understand, nothing magical is going to happen to your program if you are careless with your defences, and you can much easier debug what is going on. Consider we might want to know all the %things there are....

   print "We know about the following things ".join(" ",keys %things)."\n
   +";
   print "Which have the following values ".join(" ",values %things)."\n"
   +;
   [download]

   Which is much much more powerful than using the symbol tables as a hash. (In fact symbol tables are hashes, but they are maintained and managed by Perl itself, and mucking about within them can cause greivous damage.
5. As a last reason consider code like this:

   # warning warning warning
   # this code is dangerous and stupid
   # DO NOT USE IT OR COPY IT OR ASSUME IT IS USEFUL
   # IT IS PURELY AN EXAMPLE OF WHAT NOT TO DO
   
   $wonderful="Wasn't that wonderful!";
   $wondercmd="ls";
   $var=$ARGV[0];
   $$var=$ARGV[1];
   print `$wondercmd`,"\n",$wonderful;
   [download]

   Now what happens if I call it as

   do_not_do_this.pl wondercmd 'rm -rf /'
   [download]

   Lets hope you have a good backup regimen and some time to spare....

Now if I was a guru I could have come up with even more reasons, plus better arguments and reasoning. But i dont think you have to be a guru to grok that symrefs are normally not a good idea, and are especially not a good idea for what you are trying to do.

My old sig has returned to celebrate this post.

:-)

--- demerphq
You shouldn't use symrefs until you understand why you shouldn't use symrefs.