Symbolic references are a lot like hash keys (really like them if you dig down far enough). So if you have:

use warnings;
use strict;
no strict 'refs';

my %hash = ( badger => 'nadger', mutt => 'nut' );
# Package variable, named badger
our $badger = 'furry';
# Lexical variable - gives a warning that it is shadowing
# the package var
my $badger = 'stripey';

my $str = 'badger';

# The value of $str is used to lookup in the hash
# Hence this prints 'nadger'
print $hash{$str}, "\n";

# With strict refs off, we can use '$str' as a reference and
# so this prints 'furry', the value of the $badger package var
print ${$str}, "\n";

# This is a normal variable lookup, whose value will be
# 'stripey', since the lexical is shadowing the package var
# in this scope.
print $badger, "\n";
[download]

then you can see that using a symbolic reference is a bit like looking something up in an un-named hash. In fact, this is almost exactly what is going on, since the package variables are stored in a hash associated with the package. (The only difference is that there is an extra layer of indirection, to sort out the difference between things with different types but the same name: $badger, @badger, %badger etc.)

This means that symbolic references have similar properties to hash keys, in particular perl can't check at compile time whether you have mis-spelled the variable name, instead it will just look up the wrong name give you an undef value.

Also as you can see, symbolic references don't really have much advantage over hashes, if you think you want a symbolic reference, it is quite likely a hash will do the job for you.

And lastly, emulating a structure by using named keys in a hash shares some of the disadvantages of symbolic references. If you're using a hash reference to implement an object you can get compile-time checking back again by using accessors, made easy by handy modules such as Class::Accessor.