As my SQL Server backups are usually a mix of backup and archive:
Backup: the ability to restore a system to functionality following a problem (DML or DDL (DROP) mistake by someone who had approved access, malicious or accidental DML or DDL by someone who shouldn't have had approved access, actual attack (SQL Injection or other), heat death of the machine, hard drive tray simultaneous failures, RAID single failure + pre-existing corruption that had been masked by the RAID controller, HBA failure, power outage + RAID battery failure).
Archive: the ability to see what the system/data looked like at a previous point in time (app error investigations, bad data investigations, bad data recovery of specific subsets of data (Hey, we loaded one bad file N days ago, but the other 1,000 files and million transactions were good; fix the one bad one!) SEC retention regulations, legal investigations, etc.)
I usually keep 3-4 weeks of Fulls (weekly for Full recovery model, daily for Simple recovery model) and 2 weeks of T-logs (daily, most often), and alter the frequency as necessary.
I try to make very sure that the backups are _not_ written to the same physical disk spindles as the main DB files, as storage is the primary point of hardware failure leading to unrecoverable, or corrupt, files.
As far as corruption goes, I have absolutely seen corrupt files, but more often, I hear something like "Hey! Something weird happened! The file must be corrupt!" with absolutely zero evidence of corruption whatsoever.
I do have a plan that for some backups, I will have a separate app server generate .par2 Reed-Solomon ECC files once the backups are complete, which will allow the detection of corruption that may happen later, and the possibility of correcting it.
http://www.chuchusoft.com/par2_tbb/index.html - note that this software has a ~1GB limitation on the .par2 dataset, so a 900GB backup file can't have .par2 of more than 0.1% generated with par2_tbb. If anyone knows of better ECC software, please let me know.
As far as space goes, if your backup system doesn't do deduplication, and you're not already writing compressed backups, you could also set up compression with whatever tool your organization prefers (7-zip or other), either from the DB server (using up more DB server CPU and IO capacity) or from a separate app server.