Hello! Thank you for doing these tests!
There are other graphs I would like to see. Could you post the raw data? I suspect, for example, the average RPM (or RMS RPM which is probably actually closer to thrust) is rising with the input frequency. I suspect the CC ESC is employing active braking, which will keep the average RPM much lower in this case, and make it appear as having less attenuation because the negative delta duty cycle requests will be amplified. This should actually map to stability as well and so is important, but at some point the trade-off will be with power consumption. (Isn't your Y-scale backwards?)
I was considering implementing a poor-man's active rectification with fixed proportional diode conduction assumptions, since this should effectively produce active braking and increase efficiency at the same time, if only just to see what result it might have in a test such as this. Your setup would be useful for comparisons here.
I have a few suggestions that might be worth looking at. First, it would be useful to test Mystery/BlueSeries/ztw type ESCs with stock firmware, since they seem to have much more significant throttle input averaging than the Hobbywing/Turnigy series, and I do not believe it is affected by input rate. Also, although not directly related to thrust, measuring the duty cycle output (lag, resolution, and bandwidth) might give you data with a lot less noise, assuming you want to exclude active braking from the equation for a fair comparison of control bandwidth.
One thing I find odd with your plot is that RCTimer ESCs (<= 30A) actually all run the same software as shipped on older, ATmega-based, Turnigy Plush ESCs. So, unless the update to SiLabs MCUs significantly changed the response, I would expect the numbers to match. (Unfortunately, both have "V3.1" on the sticker.) With this code, the throttle input is averaged on every received pulse, which means that higher update rates reduce the averaging lag-time, as tested here: http://www.rcgroups.com/forums/showthread.php?t=1250488
... I suspect you will see less "attenuation" with the RCTimer ESC if you changed your test to send pulses at 400Hz, for example. This is what I believe largely lead to the believe that high update rates are required -- it just works around this implementation issue.