The actual backup may not be taking 7+ hours. If they have Verify backup enabled, then SQL does a "logical" restore, reading through the whole backup and checking each page. If you do an sp_who2 during the verify phase, you will see a database restore running, and yes I got a fright when I saw this for the first time. I recommend disabling the verify backup, and rather doing automated test restores to another server on some sort of scheduled basis. This alone may cut your backup time in half, and reduce the load on your production server and on the IO infrastructure for that server.
As Sue has said, make sure you are using Backup Compression, in which case there is no benefit in using multiple files, because Compression uses multiple files under the hood. It is worth while looking to do a combination of FULL and Differential backups. Our clients with big databases do a full backup over the weekend, then differentials Monday - Saturday. (I'm assuming you have log backups in between, or the DBs are in SIMPLE mode.) A bit of coordination may be required, say the 4TB has a full on Sat, and the 17TB has a full on Sun, DIFF for the rest of the time. You can get smart if you have different file groups and do file group backups. This is specially handy if some of the file groups are Read Only, but this may well need a lot of reconfiguration of the DB. You would need to do a bit of research and testing to get the most out of this.
Consider splitting the DBCC CHECKDB into it's subsections: CHECK TABLE on each table (maybe in subsets over a week) then Check Alloc and Check Physical over the weekend. This way you cover everything the CHECKDB does, at least once a week. Alternately you can run the CHECKDB on the database using the regular restores that verify your backups. Just be careful, you may be subject to licences on the SQL server you are using for the restores and CHECHDB.
Another idea is to use AoHA, and do some of this against your readable secondary, again, this will incur a license cost. You can do backups and DBCC checks against the secondary. AoHA also gives Automatic Page Repair, so it's possible a corrupt page will never cause a problem. Be aware that the DBCC check on the secondary DOESN'T say the primary isn't corrupt, it only tells you that you have a healthy secondary you can fail over to in the event of a DBCC error on the primary.
Nothing in life is ever so complicated that with a little work it can't be made more complicated.