SQL Server will happily take UNC's; I've seen backups to SANs, to SNAP drives on a SAN, to local disks (correctly to spindles other than the spindles holding the database and/or logs, so the loss of one array/set of spindles doesn't lose everything), to the same disks as hold the data and logs (bad: lose one array, lose everything), etc.

Personally, I'm quite happy to backup to a highly available network share on a highly robust network, as long as the throughput's present for good performance not only for the backup, but for the network as a whole, and for the target share's other users (if any). If the network and the target are very reliable, this immediately gets your backup off the database server or potentially off the main SAN, so a single crash (or potentially fire) doesn't kill data + backups.

If you're going to try backups over a network, then test your network first - run some of these and see if they work on heavy use days.

For those environments which are not as robust, then the specter of backups failing due to network issues rears its ugly head, and that's where "backup local, then copy off" is the only reasonable answer - it's just a little more complex to handle, and you have to consider how you handle each backup after the previous N copies failed (especially if you want to offer PITR from the copied backups). Robocopy's "mirror" mode may serve well here. Further, you need to increase your capacity planning to have more local drive space (though it can be much, much slower - arrays of 7200RPM SATA drives should have quite good pure-sequential performance).