Random does not imply dynamic, in your case the block size does not ramp up immediately to confirm transactions in a timely manner. For your idea it would be better to implement a deterministic variation, a large block every n blocks, so that low fee transactions can expect to wait n * 10 minutes instead of a random wait time.
That would work too.
The advantage of random is that it doesn't cause regular cycles. If there was a large block in the next 2-3 blocks, then nobody would bother paying high fees until it passes.
Random means that you don't know when the next large block is going to happen, so you have multiple market prices depending on which block you want to get into.
Fixed block sizes of different sizes and probabilities do not inherently overcome any fundamental problem a single block size has. If we calculate a weighted average of your block sizes and implement that as a new block size then the blockchain will process the same number of tx per given period, therefore the transaction in your example would also eventually be confirmed.
The proposal isn't to increase the total number of transactions, that is a separate issue. The advantage of this system is that higher fees more directly give you faster confirms.
Once there is two to three blocks worth of transactions in the memory pool, there would be a very clear market price for fees. If you pay lower than that, you are likely to simply be rejected. This softens the edge, and means that there can be a range of fees.