Actually, I'm a bit surprised that I do get the same warning with a slightly modified variant:

$ perl -Mstrict -Mwarnings -MData::Dumper -le 'my $hr; $hr->{stuff}{fo
+o} for 1; print Dumper $hr'
Useless use of hash element in void context at -e line 1.
$VAR1 = {
          'stuff' => {}
        };
[download]

As it autovivifies, it's not "useless", strictly speaking...  Also, what about (intended) side effects with tied hashes?

As it autovivifies, it's not "useless", strictly speaking..

By that logic, the following shouldn't warn since calling f() isn't useless:

$ perl -c -we'f()+123'
Useless use of addition (+) in void context at -e line 1.
-e syntax OK
[download]

You're mistaken about what gives the warning. The op that does the autovivification is not the one issuing the warning. It's the access of the foo element that issues the warning, and it's indeed useless to access the foo element.

$ perl -we'my $hr; $hr->{stuff}{foo}'
Useless use of hash element in void context at -e line 1.
[download]

is basically equivalent to

$ perl -we'my $hr; $_ = \%{ $hr }; $_ = \%{ $_->{stuff} }; $_->{foo};'
Useless use of hash element in void context at -e line 1.
[download]

The last bit is clearly useless.

If you prefer a diagram,

   ___________________ scalar context pad fetch. autovivifies
  /   ________________ deref
 |   /    ____________ scalar context hash fetch. autovivifies
 |  |    /     _______ deref
 |  |   |     /   ____ void context hash fetch. warns.
 |  |   |    |   /
|--|-|------|-|----|
$hr->{stuff}->{foo};
[download]

Similar, without useless bits:

$hr->{stuff} //= {};
[download]

Also, what about (intended) side effects with tied hashes?

Warnings aren't always accurate. That's why you can turn them off.

Update: Additions for the sake of clarity.

Well the first version also auotovivifies.... i'm not sure what you mean about tied hashes.

No, $hr->{stuff} alone doesn't autovivify the element. It's the dereferencing operation

     $hr->{stuff}->{foo}
                 ^^
[download]

that autovivifies, not merely accessing the hash element.

As for side effects with tied hashes, I mean that arbitrary code could be associated with the tied read operation.

map {$hr->{stuff}} 1
[download]

perl590delta says map in void context is no longer expensive. map is now context aware, and will not construct a list if called in void context.

if there is no list, why is there list context?

Just like about any other operator in Perl, map imposes a certain context on its operands, regardless of the context it itself is in. In:

map {$hash->{foo}} 1;
[download]

there are actually two lists, both containing a single element: the first list consists of $hash->{foo}, the second of 1.

Think of it this way, if map would not provide list context to its inner block, the following wouldn't do what it does now:

%h = map {$_ => 1} qw[foo bar baz];
[download]