Physical standby databases seem to be ideal candidates for offloading backups from primary ones. Instead of "wasting" resources (unless you're already using Active Data Guard for example), you could avoid affecting primary performance while backing up your database, especially if your storage is under heavy load even during normal (user- or application-generated) workload. So, if you're seeking for good reasons to convince your boss/finance department/etc. that having standby database(s) is a must in your environment, ability to offload backups from primary databases would be for sure important (apart from usual ones, related to disaster recovery, etc.).

Those already using their standby databases as a source for backups know that in 10g version, some workarounds were needed - for example, maintaining two separate recovery catalogs. Good news is that, in 11g version, it's much more integrated and easier, but as usual - you still should remember about some small details and implications of using such strategy. Oracle Openworld 2014 is upcoming, but if you want to find more about it (as well as some facts about our way to do backup and automatic recoveries), please check my presentation from Oracle Openworld 2012 conference, which could be found here: http://www.slideshare.net/SzymonSkorupinski/con4428-pdf-44280001. It is still up-to-date and observing ever-increasing number of reads, it seems that there is an interest in such solution.

As an additional proof (not mentioned in the presentation) that while designing 11g version, Oracle thought about improving Data Guard integration in the whole database ecosystem, I've recently found a little feature, described in 11.1 documentation (click and look for "1.2.10.4 Improved Integration with Data Guard"):

Allow conversion of a backup control file to a standby control file and vice versa. This eliminates the need to explicitly create a standby control file from the primary database.

This means that running on primary database:

RMAN> backup current controlfile for standby;

is not needed before creating the standby - it is sufficient just to use:

RMAN> restore standby controlfile;

on standby database which will restore "normal" controlfile backup and automatically convert it to standby one, as has been confirmed by simple test ran on standby database:

RMAN> run {
        allocate channel d1 device type disk;
        restore standby controlfile;
        alter database mount;
      }

allocated channel: d1
channel d1: SID=611 device type=DISK

Starting restore at 01-SEP-2014 14:46:50

channel d1: starting datafile backup set restore
channel d1: restoring control file
# normal controlfile autobackup
channel d1: reading from backup piece /backup/dbs01/DBNAME/DBNAME_c-3435486628-20140901-43 
channel d1: piece handle=/backup/dbs01/DBNAME/DBNAME_c-3435486628-20140901-43 tag=TAG20140901T143921
channel d1: restored backup piece 1
channel d1: restore complete, elapsed time: 00:00:03
output file name=/ORA/dbs00/DBNAME_NEW/DBNAMEcntrlf_01
output file name=/ORA/dbs02/DBNAME_NEW/DBNAMEcntrlf_02
output file name=/ORA/dbs04/DBNAME_NEW/DBNAMEcntrlf_03
Finished restore at 01-SEP-2014 14:47:00

database mounted
released channel: d1

In the alert.log I've found:

Mon Sep 01 14:46:58 2014
Conversion to standby controlfile pending for restored file
Mon Sep 01 14:47:00 2014
alter database mount
Converting controlfile to standby
If db_file_name_convert or log_file_name_convert parameters
are not used, then RMAN intervention is required to fix the
file names in the converted control file. Refer to RMAN
documentation for how to fix all file names.
Clearing standby activation ID 3536706354 (0xd2cddb32)
The primary database controlfile was created using the
'MAXLOGFILES 50' clause.
There is space for up to 40 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl6.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl7.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl8.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl9.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl10.f' SIZE 0;
ALTER DATABASE ADD STANDBY LOGFILE 'srl11.f' SIZE 0;
WARNING: OMF is enabled on this database. Creating a physical
standby controlfile, when OMF is enabled on the primary
database, requires manual RMAN intervention to resolve OMF
datafile pathnames.
NOTE: Please refer to the RMAN documentation for procedures
describing how to manually resolve OMF datafile pathnames.
Set as converted control file due to db_unique_name mismatch
Changing di2dbun from DBNAME to DBNAME_NEW
ARCH: STARTING ARCH PROCESSES