bareword filehandles are not protected against typos

This is not entirely correct. While a typo in a bareword filehandle will not produce a compile-time error, it will produce a warning at run-time about using an unopened filehandle, and a unique typo will produce a compile-time warning about a name "used only once: possible typo".

they clash with package and sub names ... There is no remedy for this other than "being careful"

I strongly disagree with that statement; the standard conventions in Perl are to make bareword filehandles ALL UPPERCASE, while package names are MixedCase. Bareword filehandles do not clash with sub names at all: they are distinguished by syntax in all reasonable cases and are separate GV slots. The same name is allowed to have both a CODE value and an IO value in Perl.

While not wrong, this is only true under certain circumstances: if there are multiple packages in the same file, and those packages are in the same lexical scope, and the user has similarly named lexicals and makes a typo that happens to reference a previously declared lexical.

That was not specific to filehandles, but applies to file-scope lexical variables in general. A file-scope lexical is in-scope for the rest of the file. If you define multiple packages in the same file after declaring a file-scope lexical, they will all invisibly share that value. A bareword filehandle is in-scope for the rest of the containing package, possibly also the containing file, since the parser takes its use as a hint. These scopes have the same extent. A lexical declared at file-scope is indistinguishable from a global variable in good practice. (Declaring multiple packages in the same file is not good practice unless the "inner" packages are very closely related to the "main" package in the file.)

I find this insistence quite misleading

I find similar insistences that a lexical declared at file-scope is somehow not effectively a global variable merely because it is not in the symbol table similarly misleading. File-scope cuts across all other structures in the same file defined after a declaration. All following subs close over file-scope lexicals. Lexical variables declared at file scope have the same risks as global variables (use strict / use vars) and need to be recognized as such. This is not limited to filehandles, but it is often touted as a problem with bareword filehandles. At file-scope, lexicals have the same problem.

a typo ... will produce a warning

I know, since I'm the one who corrected you about this. And since lexicals cause compile-time errors, this is an argument for lexicals instead of bareword filehandles.

"being careful" ... conventions ... in good practice

These three are the same thing, and we've been over this too.

Bareword filehandles do not clash with sub names at all

You're mistaken, see the references I gave.

That was not specific to filehandles ... These scopes have the same extent.

Once again you're just explaining something to me that I already know, while missing the point I was making: you said lexicals have an additional risk, which I agreed with, while pointing out that the scope of the potential issue is both easily remedied and the issue arguably smaller than all the issues that bareword filehandles have.

A lexical declared at file-scope is indistinguishable from a global variable in good practice.

There's that insistence again. And just in case your point happens to be that code using bareword filehandles, when correctly written, runs just like code using lexicals, then while true, I think this fails to recognize the action-at-a-distance issue I named. While the cost of this may not be immediately apparent and you may not have personally run into this so you may not know this feeling, ask anyone who's had to maintain code that uses globals how brittle that feels, or especially anyone who's had to debug an action-at-a-distance bug what that's like and what the cost was.

I find similar insistences that a lexical declared at file-scope is somehow not effectively a global variable merely because it is not in the symbol table similarly misleading.

Who's insisting this?? Not me...

Lexical variables declared at file scope have the same risks as global variables (use strict / use vars) and need to be recognized as such.

Once again I fail to see how this has anything to do with an argument for using bareword filehandles instead of lexicals.

At file-scope, lexicals have the same problem.

That lexicals and barewords share an issue or two may be true, but neither is this a counterargument to anything I said, nor is this what you said that I was responding to. Saying barewords have "exactly the same effect" while not acknowledging that barewords have more problems than lexicals is misleading and potentially dangerous to people who aren't aware of the issues. Imagine someone writing a short, single-package daemon:

print STATUSMAIL "Error report:\n";
print STAIUSMAIL "IMPORTANT ERROR\n" if some_rare_error_condition();
[download]

Lexicals would have obviously prevented this. And yes, I'm aware of "but conventions" and "but warnings" and "but testing" - I find the analogy in the anonymous post fitting: my car may or may not have a crumplench zone, airbags, and autopilot, and yes, seatbelts may not be a silver bullet, can be used wrong, and can cause bruises, but guess what, I'm still going to argue that the habit of always putting on a seatbelt is a Good Thing for many good reasons (while educating people on how to do it right when necessary), and one major reason is that there are other people on the road too. And I'm still going to take issue with people who say otherwise, and to me, "I strongly favor the use of bareword filehandles at top-level in preference to declaring lexicals at file-scope and thinking that you are safe" reads as "I strongly favor not wearing a seatbelt in specific circumstances in preference to wearing a seatbelt and thinking that driving is perfectly safe." In response to my arguments, you just seem to keep repeating various permutations of "seatbelts and driving overall aren't perfectly safe", which may be true, but is not an argument against seatbelts. And just to be clear, yes I'm equating lexicals to seatbelts because they protect against all of the issues of bareword filehandles, and I have yet to hear arguments against this.

Taking a step back, at this point I'm just seeing a lot of nitpicking, explaining things I know, and repetitions of things we've been over, and continuing the "discussion" in this manner is not helpful. So far, I've carefully read all of your posts in hopes that I'd find an actual, concrete argument for bareword filehandles (as I asked), and also arguments against the various issues that I named (that isn't nitpicking), because I was honestly curious if either exist. But at this point I'm more worried that I've insulted your personal coding style, which I said isn't why I'm arguing this, so I'm sorry if that's the case.

What I'm arguing for is what to recommend to others, in particular (but not limited to) newcomers - in that respect, my viewpoint remains unchanged from what I said: I don't really see what arguments for bareword filehandles are left, other than making newcomers to the language aware of the fact that they exist but are not a best practice.

Edit: Clarified second paragraph.

You may make your recommendations, and I will make my recommendations. What I strongly oppose is removing features from the language that touts TIMTOWTDI without very, very, very good reasons, and the arguments against bareword filehandles do not meet that bar in my view.

I have a significant background in C, where all variables must be declared and the compiler will always catch typos (unless the typo refers to another declared variable with a compatible type) but issues of scope are similar, although the available scopes and extents are different from those in Perl. I see Perl file-scope lexicals as equivalent to static variables declared at file scope in C. They can be a useful tool, and certainly are preferable in most cases to ordinary globals, which appear in a common namespace across all modules in a C program, but are still best avoided unless you really do need that variable to be in the static data segment — nearly all actual data should be dynamically allocated on the heap and pointers held in local variables or itself held in local variables. But Perl does not put all globals in a common namespace: Perl has packages, which C lacks. Perl "globals" are actually stored in those packages, and standard practice in Perl 5 is to limit the reach of a package to a single source file. Therefore, "globals" and file-scope lexicals actually have the same scope and the same risks.

I reject the seatbelt analogy for this reason. (And I personally always wear my seatbelt when driving.) From my view, this is more like an "Emperor's New Clothes" situation where people are wearing sashes (that look like seatbelts) and acting as if they are wearing seatbelts and getting upset when it is pointed out that the sashes do not actually anchor to the car. File-scope lexicals look like lexicals, but have effectively the same scope as globals. In terms of surprise action-at-a-distance, they carry the same risks.

This is not to say that lexical filehandles are completely useless at top-level, as you have mentioned before, code is often lifted out of a sub for presentation in a SSCCE, and lexical filehandles are (with rare exceptions) the only proper option in a sub, but file-scope lexicals walk like globals and quack like globals. They are not, therefore, chickens.