Simply stated, its because the diamond operator does dual service as both readline and glob. If the value or variable inside looks like a file handle at compile time, then it is interpreted and compiled as readline, if it doesn't, then it is interpreted and compiled as glob. At compile time a hash element is deemed more likely to contain a glob pattern than a filehandle.

As for why, you'd have to ask the author(s), but it is probably a throwback to when perl didn't have lexical filehandles; and it's never been seen as high enough priority to attempt a fix.

Thank you very much! This is the explanation I needed.

I found this in perlop in the I/O Operators section:

"If what's within the angle brackets is neither a filehandle nor a simple scalar variable containing a filehandle name, typeglob, or typeglob reference, it is interpreted as a filename pattern to be globbed, and either a list of filenames or the next filename in the list is returned, depending on context. This distinction is determined on syntactic grounds alone. That means <$x> is always a readline() from an indirect handle, but <$hash{key}> is always a glob(). That's because $x is a simple scalar variable, but $hash{key} is not--it's a hash element. Even <$x > (note the extra space) is treated as glob("$x ") , not readline($x)."