There is nothing more stable and predictable than a static flat limit of 8Mb per block. It's actually the most simple solution to implement as well (the patch is likely a one-liner). If some merchants and exchanges use semi-custom self-compiled clients, incorporating any sophisticated BIP implementation with voting might cause some incompatibilities and forks in the future (remember BerkleyDB to LevelDB switch).

With static limit (8Mb), we will have both an increased (competitive to other PoW coins) capacity and a potential market for fees, which should satisfy both camps if they are interested in finding consensus at all. Besides, statically capped Bitcoin with gradually increasing soft limits is Bitcoin we all know and value, it's the one that is proven to do the job. Why complicate it?

If we survive the fork (by simply raising the limit to 8Mb) and succeed, it will create a precedent for future adjustments.
In 2020 we might look at this issue again and say: "Jumping from 1Mb to 8Mb worked great, let's move to 32Mb this time if the tech allows the network to be healthy".