'id' => "$id",

Quite frequently around the monastery of late, I've noticed this practice (idiom? tic?) of (apparently) needlessly interpolating a scalar into a string. I don't understand it. Is there any benefit to be had from it? Where does it originate?

Update: When I originally posted this, I went looking for some examples of this 'frequent' practice and, of course, couldn't find any, got annoyed, gave up. Here are some recent examples: Perl function calls. and its cousin Perl : Convert a monolithic code to a function. They are both by grasshopper user786, but I'm sure he or she is not the only 'offender'. As you will see in the code of the linked posts, none of the interpolation has anything to do with avoidance of numification.
Also: System output variables and newline:  print "$dcr"; statement at end;

The only thing that springs to mind is to preserve any leading zeroes.

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Yes, you are right, AnomalousMonk, for populating the inner hashes, I just blindly copied the OP's code, but AFAICS, quotes are not needed on either side of "fat commas" in the above hash definition, so that the relevant code could be changed to:

push @people, {
               id => $id,
               first => $first,
               last => $last,
               age => $age,
              };
[download]

They are not needed on the left side of "fat commas" (=>) because the fat comma automatically stringifies its left argument, and also not needed on the right side of the fat commas here because the values are already stored into variables. And, BTW, with respect to boftx's suggested explanation, preserving leading zeros doesn't seem to be a sufficient reason, as it appears that any leading zero(s) in these variable will be preserved and that Perl will not "numify" the hash values, as shown in this example under the Perl debugger:

  DB<13>   $s = "003";

  DB<14> %h = (string => $s);

  DB<15> x %h
0  'string'
1  003
[download]

#!/usr/bin/perl

use Data::Dumper;
use strict;
use warnings;

getPeople();

sub getPeople {
        my $file = 'list.txt';
        my $people;
        open( LIST, "< $file" ) or die "Can't open $file : $!";
        while (my $row = <LIST> ) {
                my ($id, $first, $last, $age) = (split /[\s=]/, $row)[
+1, 3, 5, 7];
                $people -> { $id } = {
                                id => $id,
                                first => $first,
                                last => $last,
                                age => $age
                                };

}
print Dumper($people);
print "The person with ID 3 is $people->{3}{first} $people->{3}{last}\
+n";
close LIST;
}
[download]

This seems to be fine, but I do not understand why you insist on using a reference to a hash of hashes. Why not simply a hash of hashes? Something like this:

sub getPeople {
     my $file = 'list.txt';
     my %people;
     open( LIST, "< $file" ) or die "Can't open $file : $!";
     while (my $row = <LIST> ) {
          my ($id, $first, $last, $age) = (split /[\s=]/, $row)[1, 3, 
+5, 7];
          $people{$id} = {
                          id => $id,
                          first => $first,
                          last => $last,
                          age => $age
                         };
     }
     print Dumper(\$people);
     print "The person with ID 3 is $people{3}{first} $people{3}{last}
+\n";
     close LIST;
}
[download]

An additional remark is that both your $people hashref and my %people hash are lexically scoped to the subroutine and not accessible outside the sub. I guess you will probably need to return it to the calling routine or share it one way or another with the caller if it needs to be used outside the sub.

As a final note, I think you should compare your indentation with mine: I think that mine shows more clearly that the code after the end of the while loop still belongs to the subroutine definition. Taking the habit or properly indenting your code will save you a lot of debugging time when things get a bit complicated.