A contentious fork on the other hand is a much riskier and more damaging event.
And a contentious fork in an emergency/panic is an even much more riskier and much more damaging event.
The whole point of planning and carrying out the fork in the near term is to preempt significant growth to prevent an emergency situation where the hard fork is done in a panic. That could be even worse. It is better to do it now when people are calm (mostly) and are thinking rationally (mostly) and various proposals can be heard and discussed. You never want to fix a problem when it becomes a problem.
But there will be no emergency. If there is panic it will be unwarranted, as it is now.
Are you suggesting there won't be a panic when blocks are full and transactions are backlogged? Because that is pretty much what happened when the spam attacks happened. People panicked.
Nothing serious or bad will happen if we touch the limit. Its not a big deal.
You never want to fix a problem when it becomes a problem.
Why? premature scaling is often the cause of the death of many businesses. The reality is fixing problems when they occur is often the pragmatic way to go.
Right now people are stressing about what I consider to be an imagined problem that will not occur. I can see no clear reasoning or evidence for the emergency scenario.
Why do you consider this to be an imagined problem?
Even if there is no emergency, if a problem exists, why should you wait before it becomes serious? That is not a good way to deal with things because then you have an emergency situation.
You always have to weigh issues up individually too be honest. Sometimes dealing earlier is a good choice, sometimes not.
It might even be a good thing if we hit the limit if it creates a fee market and incentivises better scaling solutions.
If it creates a fee market, then what happens to the claim that Bitcoin is a free or low cost way to transfer small amounts of money? That vision and the whole micropayemnts thing is going to go away. It could cause Bitcoin to lose users or simply prevent other users from joining.
Also, what if better scaling solutions can't come up before this becomes a problem? If you prefer kicking-the-can-down-the-road, then you should consider BIP 102.