What technical arguments are there for discouraging bareword filehandles?

There's the lack of scoping. You could use open(local *FOO, ...) to protect the caller, though. So I guess the real problem is that lack of scope-enforcement under use strict;.

Also, they're very low on the totem pole, so they can end up meaning something unexpected.

That is a short summary of the impression that I got from previous discussions on the topic of indirect filehandles in Perl, particularly in the case of code at the top-level of the main script, where a (global) bareword filehandle and a file-scope lexical have effectively the same scope.

There seems to be some confusion here — I am arguing that bareword filehandles should remain in the language, but suggesting a compromise of making bareword filehandles lexical variables. I expect that the arguments in favor of declaring bareword filehandles (and giving them lexical scope) are essentially the rationale for use strict 'subs' prohibiting the old "bareword-as-unquoted-string" behavior.

where a (global) bareword filehandle and a file-scope lexical have effectively the same scope.

Globs (which you call bareword file handle) and other package variables are global, which means visible everywhere.

File-scoped lexicals are still lexically-scoped. They aren't seen outside the file.

package variables are global, which means visible everywhere.

Close — fully-qualified names are visible everywhere, but most "global" variables are implicitly scoped to the current package.

File-scoped lexicals are still lexically-scoped. They aren't seen outside the file.

If a 1:1 correspondence between files and packages (as is convention) is maintained, those are equivalent, with the exception that you can refer to a package "global" variable from elsewhere if you specifically do so. In terms of "accidents", the risks for a package variable and file-scope lexical are very similar.