All of these points line up to the following conclusion.
It's not that simple.
This is not an exausitve list of why.
A device may be able to handle 50 Mbit of data if the average packet size is 1000 bytes, yet only 5 Mbit if that data is at 100 bytes per packet.
Due to caching effects, analizing two pacekts from the same flow one directly after another will tipicly cost less than two packets from dissimilar flows. Due to TCP, any delay introduced by a device may cause different ACK behavior. Differing ACK behavior can increase / decrease total number of packets or change the avg packet size of the flow.
A device may be able to handle 100Mbit of traffic just fine as long as that traffic is uniform and packets arrive at a steady speed. That same device may not be able to handle 1000Mbit for 1/10 th of a second, then 9/10th of a second with no traffic. The average is still 100 Mbit on a large enough time horizon, even though that is not what is happening to the device. Any device that supports phyiscal links that are faster than it's ability to analize packetes will run into this problem.
The specifics of the situation will determine if automatic flow control helps or hurts this problem.
A device may be able to handle 20 Mbit of http traffic, but only 10 Mbit of ftp traffic.
A good example for this would be a virus scanner that decompresses files for annalysis. The decompression operation may take more resources than analizing an uncompress stream. Some data, and the annalysis on it can have large effects on argregate performance.
A device may be able to handle 100 Mbit of simple html traffic but only 20Mbits of jpg/tiff/png data.
A device at 100Mbits and %50 cpuload may not be able to work at 150Mbits and %75 cpu, or 200Mbits and %100 cpu.
A device handeling 100 flows may operate quickly where that same device at 100k flows may not do so well. Internal the device may keep track of each flow, as the number of flows increase that table will eventualy stop falling into cache and access to it will get slower, thus slowing down everything.
As everynetwork admin knows the traffic level of the network tends to varry with buisness hours. Likewise does the traffic mix. In some sites the corporate culture is such that email is checked in the morning, in others it's in the afternoon just after lunch. Another good example of human dependant network loads is whenever there is an interesting news article or video feed that users send to each other becuase it is interesting or funny.
On a device that is annalysing traffic for mallicious activity, it often takes some amount of resources to report if nay mallicious activity was found. Thus a device that can do 10 K packets/sec with no attacks, may not be able to do 10 K pacekts/sec when under heavy attack load. As an example, imagine what would happen to the device if in stead of passing each packet, had to record each mallicious packet to stable storage and send an event. Suddenly the 10 K packets become 10K disk accesses /sec, or another 10 K packets / sec or more to a reporting systems. Even with event mitigation there is going to be an added laod on the device, and thus it may not be able to pass as much traffic as in the unattacked senario.
All of these points line up to the following conclusion.
Every site is different, every traffic pattern is different. Given just packets / sec and Mbits / sec, almost nothing can be constructivly stated about a devices performance.
The best option is to do a conservative annalysis. Determine the worst reasonable cases' performance and design a solution based on that performace.
Determinging a correct worst reasonable case is beyond the scope of this document.