We already pool counter thumbnails on a per-file level (e.g. no more than 2 processes at a time for any thumbnails having to do with an original file at a time). Since pool counter calls cannot be nested, we can't add another layer of pool countering based on file type grouping anything of the sort.
The biggest hole right now is that either:
a) A bunch of new files come in quickly, say 100. There could be 200 workers rendering those files (given pool counter). Many more, 50 * 100, could also be waiting on pool counter until they timeout, tying up thumb.php even more (though at least not using cpu or bandwith). The throttling config change could help with this if low limits are picked.
b) Files come in more slowly but nobody views them until there are, say 100, and then they all get viewed at once for some reason. I'm not sure how likely this is, but it's not impossible. This would require possibly pre-rendering some thumbnails first via jobs or something in addition to the throttling config change.
c) In any case, someone could still view a bunch of non-standard sizes and could tie up dozens of processes for a while before getting rate limited for a short time (and they could repeat the process). The number of threads this could tie up is lower than (b) since rate limiting would apply before the pool queue sizes would get as large. Still, it would use a lot of bandwidth and cpu. If there was throttling that was weighted (instead of using 1 for all files), then it could help.
I'm not worried about ~7000 jobs in the queue though, as it seems to just make a backlog that doesn't take up much space.