In a more mathematical analysis, if we "start" the pool at a queue of length 0, it will grow fast initially, as the the odds it finds a block faster that the submitted shares is high. But when it will be a few blocks deep, that queue provides a "cushion" that makes unlikely the queue will empty again. The longest the queue, the unlikelyest it will empty. But the odd is never 0, only decreasingly small... So it will ALWAYS empty again sometimes, but in longer and longer intervals, and each times it empties, it will grow a bit. One can then calculate that the expected growth of the cue is that it's length will be proportionnal to the square root of the time elapsed since the last time it was emptied. The exact proportionnality factor will depend on network difficuly, hashrate of the pool, etc... (For the mathematically inclined, sqrt(ht) (where h is the hashrate and t the time) is the standart deviation of a poisson distribution, the distribution that describes the bitcoin behavior. Correct me if i've made a mistake.)
There are a lot of misconceptions in your analysis, the odds of hashing a block with positive luck is exactly 50%, thats the reason we can define good or bad luck, and how the difficulty works.
On the other hand finding a block with good luck does not shrink the queue as you may take into account the shelved shares that everyone has, so you can assume safely that unless we hit a extremely lucky streak and all shelved shares all cleared, we will never award less than 25BTC, so the queue will only shrink due to payment limit shenanigans or manual payouts.
Also can you share the code or pseucode of your graphs, I am not sure how are you doing the calculations (not saying they are wrong, just I don't see where does they come from).
Also it is fun to note that in with the last 2 blocks the queue increased another 6BTC with "bad luck"