The package { ... } part is actually irrelevant. You can reproduce this behavior with a much simpler script, which might illustrate the issue more clearly:

say_foo();
my $foo = 'foo';
say_foo();

sub say_foo { say '$foo = ' . ($foo // '(undef)') }

__END__
$foo = (undef)
$foo = foo
[download]

At the first say_foo() call, the line my $foo = 'foo' has not been executed yet. Simple enough, but now you may be wondering why you're able to call say_foo() at all at that point in the script. The short answer is, forward definitions (and declarations) are a language feature. Otherwise it would be more difficult to have circular subs (a() calls b() and b() calls a(), possibly with even more complex indirection).

To really drive the point home, it might be helpful to look at how BEGIN { ... } works. BEGIN will run the code in its enclosed BLOCK as soon as it is completely defined, so you can do something like this:

say_foo();
my $foo;
BEGIN { $foo = 'foo' }
say_foo();

sub say_foo { say '$foo = ' . ($foo // '(undef)') }

__END__
$foo = foo
$foo = foo
[download]

Consider this to be illustrative, not necessarily prescriptive. BEGIN is great, but it's not always the best tool for the job. It depends on the situation (and so I'd be happy to dive a little deeper if you want to go into more detail on what you're trying to do). I typically keep my globals at the top (and of course only using globals when necessary), and separating packages out into their own source files, and so I hardly ever (never?) need BEGIN for this sort of thing.