Pools that change coins cause stops and starts as new work is issued based on the coin that appears to be the most profitable and this will show as a lower hashrate because you are changing work (blocks).
I'd also say, that this is the main problem.
It works like this:
The miner is working on a coin, while the pool already switched to another coin. The miner submits the done work to the pool and the pool answers: "Don't give me these results, they are no longer valid, because we are already working on another coin", throws it into the bin, and the submitted work is not counted for your REAL hashrate (the "pool-hashrate"). That explains the difference between what the mining-software shows and what the clevermining-website displays.
I'd say, if a switching-pool could/would solve this problem, the profits would be much higher. Why not let the miner still submit his work for the other coin, counting that as valid, and after that giving him work for the new coin? That should be solvable technically somehow, right?
Edit: If you see this behaviour, that also explains, why setting a high difficulty is not always the best solution. The same goes for the length of the work queue. Though the miner can work better, it takes longer to solve the work, and if the pool switched over to another coin in the meantime, before the miner could submit the results, even the best results don't count. With Vardiff it is the same problem. Vardiff continously adjusts to the possible hashrate of the miner. If you have a monster machine, it sets the share-difficulty high, and when the pool switches over to the next coin, before the work-results were submitted, all is lost and Vardiff then has to readjust. So if the pool switches often, you can really lose quite a lot of your possible profit.
Again, all switching pools should really work out a solution, that allows miners to deliver their work for the previously mined coin first and count that as valid, even if the pool already switched to the next, more profitable, coin.