The issue is not the pools otherwise it wouldn't be all throughout the network with several different types of pool servers having the exact same issue.
The issue seems to be that the wallet ignores consensus in that, anytime a block is sent out with a timestamp older than the most currently accepted block, the entire chain gets orphaned to the point where that block would have been the "next block" and only blocks built on that one are then considered valid.

An overly simplified example would be....

The current chain is:
Block AAAAAB - timestamp 9:15:02
Block AAAAAC - timestamp 9:15:06
Block AAAAAD - timestamp 9:16:02
Block AAAAAE - timestamp 9:16:32
Block AAAAAF - timestamp 9:17:15
Block AAAAAG - timestamp 9:17:27
Block AAAAAH - timestamp 9:17:43

And there exists a previously unaccepted:
Block AAAABA - timestamp 9:15:04 (built upon AAAAAB)

When AAAABA gets broadcast to enough nodes, the fact that 6 blocks have been built upon AAAAAB (and rendered valid by consensus) becomes irrelevant, blocks AAAAAC through AAAAAH get orphaned and the new chain becomes:
Block AAAAAB - timestamp 9:15:02
Block AAAABA - timestamp 9:15:04
Block AAAABB - the next block the network is working on.

It creates "nice" doublespend attack opportunities for anyone using a merchant that uses less than 7 confirmations (fact, not FUD).