In a logical corruption, the contents of the block are logically inconsistent. Examples of logical corruption include corruption of a row piece or index entry. If RMAN detects logical corruption, then it logs the block in the alert log and server session trace file.
By default, RMAN does not check for logical corruption. If you specify CHECK LOGICAL on the BACKUP command, however, then RMAN tests data and index blocks for logical corruption, such as corruption of a row piece or index entry, and log them in the alert log located in the Automatic Diagnostic Repository (ADR).
Logical corruption
The block has a valid checksum, the header and footer match, and so on, but the contents are logically inconsistent. Block media recovery may not be able to repair all logical block corruptions. In these cases, alternate recovery methods, such as tablespace point-in-time recovery, or dropping and re-creating the affected objects, may repair the corruption.
Logical corruption checking is disabled by default. You can turn it on by specifying the CHECK LOGICAL option of the BACKUP, RESTORE, RECOVER, and VALIDATE commands.
I have faced sometimes after power outage index and/or table data get logical corruption due some storage issue I just started database without issue and backups finished successful ( this lead us think all is ok), but after some time when application access the corruped data the error arise and suprise you don't have backup with valid block (due recover window) then nothing will help you.
Make default the option "Check Logical" will help us identify the issue soon as possible and make possible to recover corrupted data, for those that dont want that just create a new option NOCHECKLOGICAL.