The 1-second window concern is regarding the validity of a subsequent incremental backup.
BTW, there's a simpler scenario here:
Postgres touches file. rsync notices file has different timestamp, starts copying. Postgres touches file again.
If those 3 steps happen in the same second, you now have an invalid backup. There's probably other scenarios as well.
To be clear, you don't have an invalid backup *now*, as replay of the WAL will fix it up. You will have an invalid backup next time you take a backup, using a copy of the backup you just took now as the rsync destination of that future backup.
If you were to actually fire up a copy of the backup and go through recovery, then shut it down, and then use that post-recovery copy as the destination of the rsync, would that eliminate the risk (barring clock skew between systems)?
In short, if you're using rsync, it's *critical* that you give it the --checksum option, which tells rsync to ignore file size and timestamp.
Which unfortunately obliterates much of the point of using rsync for many people. You can still save on bandwidth, but not on local IO on each end.