1st of all the resticting number of threads / streams /readers (which is mor or less the same) is set in the StoragePolicy you assign to a subClient.
If you assign multiple subClients to one StoragePolicy (which is pretty normal), the number of simultaneous backupstreams can sum up to the number of streams you defined within the StoragePolicy.
if you use multipe StoragePolicies at one time for backup (simultaneously started subClients to different SPs) the overall parallel backupstreams can sum up to the sum of streams defined in the used SPs.
If you use only one MediaAgent this might restrict the number of parallel streams to the number defined for the MediaAgent, even if there are more streams defined/available within the SPs you use.
If using multiple MAs for the Backup, each MA can handle the number of steams defined for it.
So the number of simultaneous backupstreams might be larger than the number of streams per MA.
There is another counter for the number of jobs, that can be handled in parallel by the commserve, which might also affect the number of streams in your environment.
last you find the number of reader in the subclient properies. In case of VSA, each VM can only use one reader (no further split possible). Using multiple reader will try to start more VMs for Backup in parallel (up to the number defined and streams available in SP and acting MA).
Using multiple VSA for backing up a subclient might increase the throughput. If virtual VSA are used, more ESX Server can handle the load.
Whether your environment can handle the load of 50 or 100 or 200 parallel VM backups is most of the time not a question of bandwidth but a question of the number of random / sequential I/Os which can be handled simultaneuosly by your source and destination storage.
The FC bandwitdh available might not be the problem.
When testing or doing backups try to shorten the backuptime for an individual VM, since a VM SnapShot has to be presend during backuptime and the longer it takes, the longer it'll take to remove it once the VM backup is done
try to split VMs to subClients according to their size, so the VMs in a subclient are comparable. This might result in "backup done" at mostly the same time for all VMs in a subClient. Otherwise interrupts and errors in your Backupenvironment will have a strong impact on the backup and the portion to be redone. A subClient can only be backed up once at a time. so if you have VMs which take 24h+, all VMs in the same subclient cannot be backed up once a day since the subClient's still active.