Can you expand on the advantage of using this API? MySQL documentation talks about tape. Is that all it can do?

Storage managers can store backups on tape or on disk, we can store incremental backup in a different pool and media, or we can store binary logs elsewhere. Also, backups may have different retention policies, these are defined at pools level (we backup to specific pools via this API). We can use "transactions" of a kind, when several files/objects are backed up, and they are either successfully processed or all failed (and do not waste storage) etc. We can also check what kind of backups exist, their properties etc. When restore is needed, we just request specific objects from the storage manager and let it deal with the details of what volume to get them from etc.

See http://archive.opengroup.org/publications/archive/CDROM/c425.pdf also for details.

Oracle decided to implement a limited integration with storage managers, just enough to integrate MySQL into their existing "backup to tape" solutions, but we can do better!

The ultimate goal for DBA can be the following: provide a timestamp of the moment in the past that you want your data to be restored to, and let a combination of XBSA-enabled backup tool and storage manager to find the best combination of full and incremental backups (and log backups, if needed) that must be restored/applied to "get there". I had all this as Informix DBA with onbar back in 2000 or even earlier. Surely, one can achieve this with some regular storage of backups and smart shell scripts... eventually. I am yet to see this done, tested and shared in public.