Ok - so it sounds like you agree that the return value of calls like open and opendir should always be checked. Whether or not the result of a failed call is to cause the program to abort is definitely a matter of design.

However, note that there are at least two other ways to catch an open ... or die. There's $SIG{__DIE__}, and there's eval, the latter of which can be made even more useful by a module like Try::Tiny. For CGI scripts, there's CGI::Carp, and other web frameworks have similar ways of gracefully handling errors. And when correctly configured, cron will email warning and error messages to someone who can deal with them.

Also, since you so clearly state that 'There are only two situations where you should use "open or die".' and 'a plethora of situations where "open or die" is definitely not the right thing to do', I'm going to disagree with you there, on a more philosophical note. You said 'I didn't bother with the "die" or an "else" statement' - in a situation like that, I would still always write either ... or die $!; or at least warn if it really is acceptable for the program to continue in the case of a failure like that (and in my experience, those are much more rare than the cases where it's better to die).

Code has a way of sneaking into production; copy & paste is many a programmer's best friend. In the case of the code in question, the opendir could fail silently, and the program would give the wrong result; if it had warnings enabled, it would give confusing messages like "readdir() attempted on invalid dirhandle" to the user instead of "Failed to opendir /foo/bar: Permission denied" (and that it's better to Use strict and warnings is attested to by the fact that the code contained a mistake that warnings would have helped catch). So I still say it's better to always, always die or otherwise handle the error.