Not directly related to your observation, but maybe still interesting in the wider context of autovivifying things...  While trying to get some third-party code to run under strict, I recently stumbled across the phenomenon that something like

if (%$href) { print "has elements" }
[download]

produces "Can't use an undefined value as a HASH reference" when $href is undefined (under strict, that is, works fine without strict), while

my @keys = keys %$href;
my @vals = values %$href;
while (my ($key, $val) = each %$href) { ... }
[download]

all work fine under strict, because they autovivify the hash.

(The former case - which could also be written as scalar %$href - is supposed to test if the referenced hash contains elements, with the special case that the hash doesn't exist at all being semantically equivalent to "has no elements").

The explanation based on aliases being created (implying lvalue-ness) only holds partially here: evaluating the hash in scalar context presumably does not create aliases (so the behaviour is "as expected"); values does create aliases (so that's as expected, too); but keys does not create aliases, at least not in a way that you could say

for (keys %$href) {
    $_ = "foo";
}
[download]

and have the keys in the hash be modified.  Still, it obviously autovivifies.