The main driver for choosing one over the other is whether you want to maintain changes to the VDB. Method #1 is more difficult and time consuming, especially for large numbers of VDB's. But Method #1 will preserve changes.
Practically, many users choose option #1 because they want to test the DB Upgrade on non-PROD VDB's.
Ex: You have a new version of your software in DEV (VDB) which you want to test with the upgraded DB version, but this software isn't in PROD (dSource). Method #1 allows you to test the software on the new DB version without redeploying it.
Ex: You have 25 VDB's to upgrade. Use method #2 wherever possible.
There are two elements of an Oracle Upgrade: binary changes and data dictionary changes.
Binary changes are accomplished by installing a new Oracle Home and mounting the database with the new binaries. Binary installation is performed on source and target environments through the standard Oracle tools. Delphix must be made aware of the new binaries by refreshing the environment, and by clicking on the Upgrade icon.
Data Dictionary changes are accomplished by running Oracle scripts. DD changes can be propagated from source to VDB via VDB Refresh or by running the appropriate scripts on the VDB.
Because a VDB is just like a regular database, DBA's can use standard techniques to perform the upgrade, with one small twist. Delphix must be made aware of the location of the new binaries.
Upgrading the VDB independently allows you to preserve the changes made to that VDB, and get to the new Oracle version.
Logically, this is identical to removing the VDB and recreating it with the new version of Oracle binaries, except that the VDB name and other attributes will be preserved.
Changes made to the VDB will be lost.