@ISA is used as a package global. It also happens to be how Perl keeps track of inheritance. Now you may mostly be able to ignore that it's being used, by using the base or parent pragmas, but it's still there if your package inherits from something.

So if "building any of the big Tool" includes building classes that inherit from other classes, you can't avoid using package globals.

If you tried using "my @ISA", it just wouldn't work out; the inheritance chain needs to be recorded in the symbol table, not the lexical pad, because that's where Perl will go looking for it.

Even a module that just exports its functions will usually rely on Exporter by saying something like, "our @ISA = qw( Exporter );... and at that point you're committed to using other globals like @EXPORT and/or @EXPORT_OK.

The justification is that this is how it's done. You shouldn't need more justification than "because that's how it's done, and it generally works."

Now if your question is asking about some other application of package globals, you'll need to be more specific. The symbol table is a powerful device, but not always the only (or even the right) tool for a given job. The barometer for justification in the more general case should be (1) Is it maintainable? (2) Does it work? (3) Is it the simplest approach?