I don't know about the risk in terms of hard numbers, but the benefit of multiplexing N jobs to 1 tape drive while they run is you can start all N jobs at the same time (so you're not waiting on the first guy to finish with the tape before the next one can start backing up).
The big downside I see in doing this is it winds up interleaving your backups. Where right now you may have a tape that has
AAAAAAABBBBBBBBCCCCCCCCCC on it multiplexing will give you an interleaved tape that has something like
ABCABCABCABCABCABCABCABCA on it.
When you go to restore "A" from that tape your tape drive will have to skip over all the Bs and Cs in the way. This slows down the restore, and adds some wear and tear on the tape/drive as it fast-forwards (in terms of risk, there's an increased chance of snapping a tape as a result).
joeqwerty and ErikA both pointed out the solution I use and recommend if you have the disk space for it: Stage everything to disk first, then write it out to tape contiguously. This lets the backups on your machines "finish" (the data is backed up in the disk staging area) and lets the backup system put that data on tape in a logical, contiguous fashion at its relative leisure: You don't care if the tape keeps spinning for 6 hours or 16 hours as long as it's done by the time you start your next backup.
If you don't have the disk to stage everything you can still minimize the break-up by staging as much data as you can. Ideally you would stage up to the size of a tape per backup client if possible (so if server
A has a whole tape's worth of data it might be contiguous on one tape, or at least only spread over 2 of them), but half-tape or quarter-tape staging areas can still help with performance and minimizing fast-forward operations..