What to restore is very important, but it is not the only point.
Which point in time should the recovery be?
Recover Point Objective (RPO) is from the business side the most important point. For a physical disaster this will most likely be the last committed transaction. For logical corruptions it will be earlier, close to the point of the corruption. With Oracle's recovery capabilities it is possible to get a consistent database as long as there is a backup of an old enough database and all necessary redo logs (archived and probably online). Redo logs are essential for the recovery and the protection has a high priority. Oracle uses for this a special purpose appliance to ship redo logs and redo transactions to the appliance. Partial restores (tablespaces, datafiles) and applied recovery is as well possible.
What time is necessary for the restore/recovery?
The second important point is the time for restore/recovery. Recover Time Objective (RTO) has the biggest impact on the backup and restore/recovery methodology. The general demand for this is to be up and running in 0 time. This is of course not possible, but with a backup method optimized for recovery time the time can be reduced.
Three phases are time consuming during a restore/recovery.
The first phase is to determine what are the objectives. Recovery to the last transaction due to a physical issue, in a consistent state after the last backup (for a baseline revert) or to any point in time between. the restore items are dependent on this decision. All datafiles, selected datafiles or even a clone database with a logical export.
Second phase is the restore phase. The items restored should be as close as possible to the recovery objective and as complete as possible. Incremental and differential methods request multiple restores, the base line backup and all increments/differentials after. Full backups are the fastest way to do a restore, just one copy of a file. Some backup applications try to have a virtual full backup constructed out of incremental backups to overcome the restore penalty with incremental backups.
Third phase is recovery. Online backups are per definition not consistent, so a recovery is necessary. Any point in time that is later than this time requires to apply additional redo logs. The time to apply redo logs varies, but as this is a pretty single stream task. It is not uncommon to reserve for the recovery the same time, even more than the restore time. For large databases with a high write transaction rate this can easily be a multiple day job.
Now we have the restore/recovery aspect illustrated. With this background we can check what are valid backup strategies.