I'm not sure this is the case, or at least it is not as simple.  With hashcash proof-of-work it is impossible to look for lower difficulty shares without also looking for higher difficulty shares.  In Primecoin, on the other hand, as I understand it, one could look for chains of length 7 and find them with much greater frequency than they would find chains of length 7 while looking for chains of length 8 (i.e. pool miners would maximize their share submission by hurting the pool; the tragedy of the commons ensues).

I assume that when the mining algorithm executes it first executes the Sieve of Eratosthenes to build a list of possible primes.  If one finds that there is a list of 7 numbers that passed the sieve and form a chain then they could be checked to see if they form a valid share, even if the sieve eliminated the next value, proving that a block of difficulty 8 or higher is impossible from that start (I am assuming a share difficulty of 7 and a network difficulty of 8 or more).  A miner optimized for finding valid blocks as fast as possible would save computational time by ignoring the chain of length 7 when the difficulty is 8 or higher, while a miner optimized for finding valid shares would check every chain of primes that passes the sieve that is at least (share length) long.

This could be circumvented by requiring the numbers after the share's chain up to the integral network difficulty to all pass a sieve, but I believe that that would break the requirement that shares be fast to verify by the pool host.  Additionally, it would set stringent requirements on how the numbers would have to be sieved which would limit improvements to be made in that area (which seems to be where most of the improvements are being made).

You've made a really innovative coin, Sunny, and I trust you to come up with an innovative solution to this, but it isn't as simple as it may appear at first glance.