My speculation would be that the problem lies at a deeper level, which can be summarized as follows:

• Blocking mode refers to waiting until a file descriptor becomes readable/writable, but regular files are defined to always be readable/writable (granted appropriate permissions) — POSIX spec, IIRC.  In other words, non-blocking I/O with regular files doesn't really make sense (it only makes sense for sockets, pipes, fifos, etc.)
• Something is made to appear as a regular file via the sshfs mount which in reality involves a potentially failing network connection. And (presumably) the non-blocking flag either simply isn't handled properly at the lower levels of the sshfs implementation (where it could possibly be determined if the operation would block), or it's already being ignored earlier on due to having been applied to a regular file.

In short, if an alarm doesn't even work with PERL_SIGNALS=unsafe (which would be the case, if the system call is in a non-interruptable state), I think all you can do is to create a second process/thread which is responsible for killing the other process in case it blocks for longer than a specified period.

The problem with this approach is, though, that if the watching process is the child, it would kill the main program in case of timeout (usually undesired). Or, the other way round, if the child is doing the potentially blocking operation, you wouldn't easily have access to the handle from the main program in case the open succeeds...

Once you've solved this issue, you can start thinking about portability.