But think about what not having those variables means.

No other language I know of allows the application programmer to write a standard piece of code:

while( <$fh> ) {
    processRecord( $_ );
}
[download]

And with that standard, recognisable, picked-up-in-the-first-week-of-programming construct, can process any file. Regardless of whether it uses *nix conventions, or dos conventions or Mac conventions or network/socket conventions. Or if it is uses fixed length records. Or paragraphs.

The same common construct deals with all these by simply changing the value of one variable.

You want scope for errors?

Most runtime libraries have readline() and writeline() subs or methods, but the record separator is hardwired.

Want to read or write a *nix file on a dos machine, or MAC file on a *nix machine? Then you have to implement it yourself and move to using low-level reads() or getc() and doing your own buffering. And repeat the exercise for each input type. And each output type. And every programmer on every platform has to do the same.

Every facility Perl provides is there for a reason: to simplify the life of the programmer and move as much code into the thoroughly tested and supported RTL and core as possible. The more the core does, the less the programmer has to.

And all the current vogue for rejecting and deprecating Perl's features, on the basis of OO orthodoxy, or one-size-fits-all "best practices" does, is create the need for every programmer to re-invent those features themselves.

And that simply creates the scope for errors, not prevents them! And all for the sake of less need to educate and cheaper programmers. You see a good ROI in that?