To be honest, I haven't looked in quite some time (a month or so) but I know that at one point, I was testing a client that ended up spamming a large number of getworks to his server for a few seconds, and I noticed the pool speed dramatically increase at the same time. It could have been purely coincidental, which is why I said, "as far as I know".
My pool calculate hashspeed from submitted shares, not from requested getworks, of course.
Your reverse engineering failed. I publishly noted that there were bugs in getwork/s and hashrate/s meters. To explain that: I'm writing operational stats to database in sligly delayed fashion, so stats are queueing and then processed in batch (the delay is ~5 sec, so nothing dramatical). The bug was caused by race condition in writing actual stats queue to database, so in case of server overloading, more threads processed the same database write and the info about actually processed shares doubled/trippled/quadrupled. This affected only stats page, no calculating shares/score for users.
So when you overloaded the pool (thank you), you triggered this bug. It was fixed few days ago.
In my particular case, I only requested ~100 getworks over the course of 4 - 5 seconds, so it was just a coincidental increase that I saw. I can't account for the actions of others though. I wasn't "reverse engineering", just making an observation, which I stated from the beginning that it could have been a misconception. I do appreciate your clarification of the matter though. Good form.