I'm pretty sure that you are looking at legacy concerns. Recall that the Perl5 manual was released in 1994 and that it was just an edit of Perl4's manual from 1991. In those days it could probably be said about the oft-named Nightmare File System that "it isn't how well the bear dances that amazes, but that it dances at all".
NFS2 in the 1991 epoch was slowly crawling out of Sun into other platforms and was relatively crude. The security model was essentially non-existent (root on a client machine could read the full contents of an NFS mount) and locking - via nfs.lockd - was this side of experimental. You would have been foolish to expect flock semantics to work properly if at all between two different allegedly interoperable implementations. Coax was the dominant Ethernet PHY at the time which many network users have never had the displeasure of using (what do you mean you forgot to put the 50š¯›€ termination resistor on?) if that gives you a better grip on the state of intranets then.
Larry Wall and crew had every reason to make pessimistic assumptions about the correctness of NFS locks at the time, and this is the sort of defensive programming that future code jockeys are loathe to remove because it is so hard to prove the absence of a defect by removing old code which is re-introduced in interoperability with a legacy system that you never even heard of.
Since then, NFS has improved considerably, and lockd has migrated in time to a feature of the Linux 2.6 kernel. For a collection of 2003+ systems, NFS file locking can probably be trusted, especially if tested well within your application across the many platforms it may be running on.
All of the above was cribbed from memory, and could likely be substantiated through research (e.g. http://nfs.sourceforge.net/) but the proof - as they say - is in the locking, and if you didn't test it, it is presumed broken.