There's faulty logic in it: Mentioning how many years he's been usung unRAID is somehow supposed to be a proof that what he's saying is correct. The fact remains: Simple parity code can only detect an odd number of bits in error. It cannot detect the position of the error, therefore it cannot correct errors.
http://www.raid-recovery-guide.com/raid5-write-hole.aspx
Garycase said exactly the same. You can use existing backups (as him) or md5/crc hashes (as I'm doing) to detect the actual data error.
Bases on both Garycase and my own experience, whenever there were errors during the parity (correct) sysc, the errors always was in the parity information.
The 'errors' from the main unraid interface only detects errors during read/write, and not perse the example you gave where a bit just changes value without writing/reading it. But your hdd also stores a crc for each sector and will throw a crc error when such a sector is accessed (and thereby also have unraid show an error).
From what I know, in this case (hdd throws a read error), unraid will automatically try to reconstruct the sector from parity and write it again. If writing then fails, the drive will be redballed, if the write succeeds (because the sector is fine, or the hdd remaps it) everything is ok again.
Only question for me is if the 'read which causes the correct' is also triggered during a parity (correct) sync....