And therein lies the rub, there's currently no way to forecast or determine the limits when it comes to the capability of the network, other than asking nodes directly to set their own individual preferred caps. Somehow I doubt many people on these boards would consider implementing ideas borrowed from Bitcoin Unlimited. 
Joking aside, combining algorithmic blockweight adjustments with the allowance of each node to set an upper limit to the size they'd be willing to accept would work if it weren't for the fact that it could easily force nodes off the network in a hardfork if they set their own personal limit lower than that of the majority of other participants, so even if people were willing to take ideas from BU, it still has some pretty serious shortcomings. If anyone can come up with a solution to that conundrum, I'm eager to hear it. Until then, it's a sticking point. Which is why all I could really do is make any increases as small as possible and allow the network to undo the increase if and when the demand isn't there anymore.
In essence, any attempt to place any hard upper limit inevitably results in hardforks at some point in future, unless you're an absolute genius and manage to find a workaround or hack to implement it as an opt-in soft fork.
Joking aside, combining algorithmic blockweight adjustments with the allowance of each node to set an upper limit to the size they'd be willing to accept would work if it weren't for the fact that it could easily force nodes off the network in a hardfork if they set their own personal limit lower than that of the majority of other participants, so even if people were willing to take ideas from BU, it still has some pretty serious shortcomings. If anyone can come up with a solution to that conundrum, I'm eager to hear it. Until then, it's a sticking point. Which is why all I could really do is make any increases as small as possible and allow the network to undo the increase if and when the demand isn't there anymore.
In essence, any attempt to place any hard upper limit inevitably results in hardforks at some point in future, unless you're an absolute genius and manage to find a workaround or hack to implement it as an opt-in soft fork.
To add to this, it would also be extremely vulnerable to bad actors, potentially with agendas favoring altcoins such as Bitcoin Cash which seek to become the "main" Bitcoin. For instance, a malicious user could start up thousands of nodes which would all attempt to bloat the block size as much as possible every block for Bitcoin's scaling to become unsustainable. This would mean, effectively, that there would be no limit to the growth of the block size
Well, there would still be the algorithmic limit of not increasing more than 0.01MB every difficulty period (and even then, only if there were adequate fees to ensure it wasn't just spam), plus the chance the blockweight could reduce again if there were a less busy period, so it's not like the inclusion of individual node caps would make it easier to increase the blockweight. But yes, it still wouldn't be ideal in that it's just not a particularly robust precaution.
That said, if it weren't for the issue where it would likely cause hardforks, I'd still throw it in there anyway as an additional obstacle an attacker would need to overcome. I'd throw in any and all additional layers of protection that make it require more effort to game the system and wouldn't result in more future hardforks. The problem is just trying to think of practical things that would work. But since individual node caps won't work, we need to come up with something better.
It's a weird quandary in that trying to limit an increase always sounds like a softfork in theory, but when you actually try to implement it, it tends to result in hardforks in practice.