The difference is in determining the source of truth for the file.
If both copies are readable and differ it's difficult to determine which file is correct. One might want to assume that the file with the newer modification time is more recent and therefore the correct one, but this is a dangerous assumption (see the reference post in my original post where Rob had to chkdsk a drive resulting in a file with a newer modification time but was 0kb). Doing the wrong operation here will result in data loss, and so it's in DrivePool's best interest to pose the question to the user and have them manually resolve it.
In the case where one of the drives flat out fails to read the file the situation is different. The safest course of action is to again ask the user what to do, but this is not what other RAID type of systems do. If all the other drives do not produce a read error of the file we might assume that their copy of the data is correct. If the other drives' view of the file is correct, we can "heal" the bad drive's copy by writing the file back from the good drives back to the bad drive.
Many parity based RAID systems take this approach. This silently handles a bad sector on the drive and we can continue operating without having to involve the user. The window of data loss is mostly closed; if we write the contents of the readable disk over to the unreadable disk, no extra data was lost other than what was already lost from the bad drive.
Whether or not this is the correct course of action is debatable. My question is what DrivePool is implemented to do in this scenario. It may be that they do as you say and always leave it as a manual operation for the user to resolve. However, DrivePool could match what other parity RAID systems do and silently repair instead.