It would have had some reasons, like better parsing speed for the client or predictability for the future size of the blockchain.
However, I did a quick search and now I know that I was wrong and I should have researched before talking. Sorry.
I will leave my post as it is now, because others may have the same misconception and my learn something of it, especially if they are as lazy as I am.

So.. the block is already variable with upper limit so all I said was on the wrong assumption.
Now I am puzzled why there's so much debate on increasing the block size, since the "effort" of the blockchain would not be so big.

From what I've read and understood, even a completely dynamic blocksize is achievable without much of a change, since in the block, the bytes 4-7 (0-based) tell the total size of the block, which can be a 4 bytes = 32 bits number, so up to ~4GB (!).

~~~~~~~~~~~~~~~~

Now back to the original discussion:
1. If 100% dynamic block is an issue, then fix the issue or limit it (even if limiting it makes it work like now), but at least limit it to something a couple of levels higher than what we have now (much higher than 2MB).
2. Such move may need a fork and then SegWit can be even forced "in the same package".


I know that this kind of move would cause more debate, but.. we have it already and we can see that SegWit is not adopted by the ones that should