It's a matter of precedence: || binds "tighter" than or so you've in effect written opendir( FOO, ( "." || die "..." ) ). The die is silently optimized away since it can never be reached (since the constant "." will never be false). See perlsyn for more details.
As for newlines, while it's not common there's nothing (at least on POSIX systems; I'm sure someone will chime in about Wintendo land . . .) that prevents you from having a newline character in a filename. You can make one yourself with perl -e 'open( my $f, ">", "foo\n" )' (and then when you do an ls you'll see something like foo?, or foo\n if your ls supports the -b flag).
At any rate, my point was that in the majority of cases you're not going to have a newline on the end of a filename so calling chomp is wasted effort. In the rare case where some joker did go and put a newline (or some other wonky character) into a filename if you muck with it to remove newlines or what not you no longer have a the real filename (the strings "foo" and "foo\n" are two different things because whitespace is significant in filenames; attempting to open the later by giving it the former isn't going to work).
(And to save everyone who blithely tries my open example above frantic googling or indiscriminate rm invocations, perl -e 'unlink( "foo\n" ) will clean things up :)
Update: Minor tweaks to wording of 2nd para.
In reply to Re^4: readdir return nul string
by Fletch
in thread readdir return nul string
by marscld
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |