This was true once - once upon a time drives were smaller (and slower), as were tapes. If you have a large raid group, and suffer a (compound) fault - all data on that raid group must be recovered.
As sizes increase, so too do the numbers of tapes required.
So a large filesystem, where you're doing a full restore might mean recovering everything and doing so from a sequence of tapes where you recall full backups and subsequent incrementals. On a large file server, this can be very time consuming.
Similarly - the backup cycle could end up taking a very long time - there was a very real danger that you'd not be able to complete your 'daily' backup schedule every day.
So instead what you would do - create separate filesystems on separate physical devices, and back them up independently. You could then stagger you backup or stream to different tape devices. If a failure occured, you'd replace and restore just that segment, and be done.
These reasons still apply to an extent, but drives and tapes are bigger and faster. (And plenty of people back up direct to disk anyway). Automated rebuilds are smoother too.
So now, they key reasons to partition are:
- control over space usage. You don't want a user to blow away 'root' because they downloaded too much junk into 'home'.
- Segregating 'things you need to back up' from 'things you don't'. If your automated rebuild process is smooth enough, you should be able to rebuild faster than you recover, and you then just add the transient data (database files, user data etc.).
- Segregation of disk config. You probably don't need high performance or high resilience disk throughout. You may then choose different disk tech or RAID types.
- disk layer backups - you can snap or clone, but usually you can only do this at a per LUN level. This tech enables some quite cool recovery/roll back/forward options, but it's necessary to segregate the storage you're doing with. (You don't want to wipe your home drives each time you roll back an Oracle DB)