a LIST in scalar context is the last element from the list.

Not always:

sub return_list { return 3, 2, 1 }

my $result = return_list();
print "$result\n";

$result = 3, 2, 1;
print "$result\n";
[download]

But = has slightly higher precedence than , so that second example is really parsing as if parenthesized ( $result = 3 ), 2, 1; rather than $result = LIST (and you can get the same behavior out of both the sub call and the scalar assignment by explicitly parenthesizing it as $result = ( 3, 2, 1 );). I don't think that disproves anything . . .

Update: using B::Deparse shows the differences:

$ perl -MO=Deparse,-p,-q <<'EOT'
sub return_list { return 3, 2, 1 }

my $result = return_list();
print "$result\n";

$result = 3, 2, 1;
print "$result\n";

$result = ( 3, 2, 1 );
print "$result\n";
EOT
sub return_list {
    return(3, 2, 1);
}
(my $result = return_list());
print(($result . "\n"));
(($result = 3), '???', '???');
print(($result . "\n"));
($result = ('???', '???', 1));
print(($result . "\n"));
- syntax OK
[download]

Update: Tweaked wording in parenthesized phrase slightly to hopefully make it clearer what I was referring to. I definitely agree it's a tricky case, but I'd say the problem is more "Everything that looks to the eye like a LIST in scalar context isn't" than a case where a LIST in scalar context isn't the value of the final element.

The cake is a lie.
The cake is a lie.
The cake is a lie.

I don't think that disproves anything . . .

Parentheses don't make lists, though. Commas do. I agree that the higher precedence of the assignment operator is important, but it's very much not the case that all evaluation of lists in scalar context returns the final element of the list.