Actually, I was thinking about hopping without using the pool's published stats at all. When a block is found on the network which is not by any of the transparent pools, assign a certain probability to it in being from each of the delaying pools based on their hashrate. Calculate expected efficiency for such pools based on these probabilities. When efficiency is higher than other pools mine there (this will usually be when several hidden blocks are found in a relatively short time).
This is sort of what I've attempted to do with poclbm-autohop (there's a thread about it in the mining software forum). The only thing that's ultimately pulled directly from the pools is the list of solved blocks. The biggest problem is that it relies on an API I compute on my own machine and update online when it changes. This makes me (and my computers) a major point of failure.
Actually, for each block that could possibly be each pool's last block, it calculates the expected efficiency if that block, and then does a weighted average of the efficiencies over all possibilities for the latest block.
Results from BTC Guild suggest that it works relatively effectively, but collecting enough data to be sure (or automating the data collection) is more work than I have yet wanted to do. Also, the system would have to be modified to handle hopping a pool that doesn't report any of its blocks.
In short: stat delays make hopping slightly more difficult, but they won't eliminate the problem, especially as techniques such as this become more common in the various hopping softwares.