|Do you know where your variables are?|
Calling "\n" a "logical newline" like you have, and like some versions of perlport do, does more to confuse than to enlighten.
That same logic would call "a" a "logical lower-case letter A" that actually represents a bit pattern that varies from place to place. So, sometimes, if you want a specific bit pattern, then you should hard-code the bit pattern and not use "a" directly (insert here code that sometimes sets $a to be a specific bit pattern, etc. and then uses "$h$e$l$l$o" instead of "hello" to be "portable").
It sounds good and is even correct to some extent. But it leads to people writing less portable code and a lot of confusion.
See Re^4: Line Feeds (rumor control) for much about this.
The code you quote is 50% due to a design mistake in the C compiler on old Macs that got propogated into Perl on that platform. The other 50% is due to a quirk of the most common VMS-based web server.
None of it is based on general principles of portability, which call for just using "\n" which is simply "the newline character in that system's character set". Needing to use something other than that as newline simply means that your system is either missing a translation layer it should have (old Macs) or has extra translation it shouldn't have (the most common VMS web server).
The comments in that code are a bit misleading as well. A better version would be:
The "logcial newline" idea confuses translations of newlines in I/O that are common to C-based systems (including Unix) with the above Mac mistake. It confuses the newline character with the end-of-line sequence. It encourages bad practices that happen to work on Macs and ASCII systems.