First of all, the reasoning used in the quote doesn't really apply to hashes and arrays since they start out empty more often than none. That's probably why the quoted practice refers to undefined variables (which can only be scalars) instead of uninitialized variables. For example,

my @results;
while (...) {
   ...
   push @results, ...;
}
[download]

Secondly, I don't agree with the quoted practice for scalars either.

If it's that hard to tell if a variable was left undefined by accident, the solution isn't to add a useless initializer, it's to fix the documentation (maybe by adding a comment) or clean up the code (maybe by localizing your variable better). For example,

my $found = 0;
my $match;      # Only meaningful when $found is true.

...
[download]

If your goal is to avoid accidental omission of an initializer (as the quoted practice states), conditioning yourself to always add an initializer isn't going to help. You'll just substitute another problem (initializing your variable incorrectly) for the one you are trying to fix (forgetting to initialize your variables).

And honestly, how big of a problem is forgetting to initialize your variables? Warnings do an excellent job of finding those instances. The cost (clutter) doesn't warrant the price.

That said, I don't buy your coworker's argument either. I feel that initializing a variable using a BEGIN block on the next line is well within the sentiment of the quoted practice, so I think his counter-argument doesn't disproves anything. Tell me how anyone could think anything but "the lack of definition is intentional" in the following:

my $var1;
my $var2;
BEGIN {
   $var1 = ...;
   $var2 = ...;
}
[download]