The consideration given is that, unlike the original proposal, this one doesn't double the blocksize. It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want. I've even stated that the 12.5% part is open to negotiation, but it is a hard cap. It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time. The period of time in question is also negotiable. This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.
12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it

I'm pretty sure that we would be much better off if we had a dynamic block size limit (with the correct parameters). BIP101 is probably too big, and 12.5% YOY might be too low, both of these would eventually cause issues. As DooMAD said, it is still a hard cap which can't be changed without another fork. If we had a dynamic block size then we would not need to worry about this (unless someone tries to game the system).
I've always been against making pointless predictions as we can not know what is going to happen in the future. We can't expect any
fixed solution to be the right call.
Not sure where the YOY part came from, heh. That's a little
too conservative for my tastes. 12.5% per month at a stretch, maybe. But again, the increase/decrease would only occur if
a) the miners agree
and
b) the traffic is actually there (or not there as the case may be)
If anything, the blocksize limit would likely reduce at first if we aren't currently filling 1MB blocks. But the important part is we don't suddenly hit a wall where a backlog of transactions can't be cleared
and we preserve decentralisation by not making it prohibitively expensive to run a full node. Happy compromise all round.