or die works regardless of there being parentheses or not, it's the same number of characters and it implies flow control so there really isn't a good reason to use ||. Using too many extra (for some value of too many) parentheses makes code harder to read, write end edit correctly because of the burden of ensuring the parentheses are matched correctly. Understanding operator precedence for at least the common operators is a prerequisite for using a programming language effectively and clearly.

I have almost the opposite view on the use of \n in a die in the context of a file open failure, but that's because most often I'm writing tools that perform few opens and almost always very early on in processing. In those cases the file name and failure mode are the important information and the actual line number is noise, especially for users.

The way you write 10 line code fragments should be very little different than the way you write larger fragments. Getting into the habit of writing robust code will save you time in the long run.

One security issue that generally arises with the 2 parameter open is that people who use it generally also omit the '<' which allows a bad person to supply a '>' instead with fairly obvious results. A more subtle and much nastier way to subvert a two parameter open is to prefix or append '|' to the 'file name'. The file name then turns into a command line which opens all sorts of interesting possibilities to to nasty minded. The burden of using the three parameter version of open compared with the two parameter version is so slight that there is almost no reason not to use it.

Fair enough, some difference of opinion, but appears to me pretty similar.

Too many parens is as bad as too few. I use parens on most sub calls with some Perl bareword exceptions. print, join and some of those things... I always use paren's when calling my own subs.

Actually as you can see, we have the same philosophy of coding:
1. check args...first thing...
2. open files..very early in processing..
3. do processing

For user errors, I find for my users (who aren't that sophisticated), my error message is enough in the "die", "can't find APP X's config file $path/.ini" or similar is enough. If they can't figure it out from that, then I want to know the line number. The $! info is noise to them. That is "in-between info" and I put it there for more sophisticated users. So I do put it in there.

On open's, well fair enough. 3 parms is "better", but I can't say that with authenticated users 2 parms like I did is bad. But few extra characters is no problem.