When you get punched in the mouth, you just adjust your plan based on new evidence, you don't throw it out the window.
Besides, business and engineering are not like fights and battles. Sudden shocks are rare and split-second decisions are not often called for. In most cases new evidence comes gradually, there is time to validate it, digest it and re-tune expectations and strategy.
Furthermore, always acting on the main immediate priority/bottleneck rarely leads to optimal speed. In computer science, this is called a greedy algorithm. They are indeed simpler to implement and tune (and to execute by teams), but rarely optimal. Real speed requires making predictions and adjusting them as more information becomes available, this is what planning is.
I interpret the Mike Tyson quote differently than you. What he was saying that under high pressure you _will_ throw stuff out of the window, namely all the stuff that doesn't work under pressure, in difficult situations. This is why plans need to be simple. You need to be able to keep them in your head when shit hits the fan so you don't start flailing around like a headless chicken.
Even when it is not so, coordinating people to execute a plan is also hard, and predictions become much less reliable with over-complicated models of reality. Simplicity is definitely an important factor.
"No Plan Survives First Contact With the Enemy"
Hard disagree:
Those things are important, but I’ve seen teams with those qualities spin or fail to produce impact because they don’t have a strategy.
You need an objective and you need a plan to get there — “objectives and key results”.
Communication and agility allow for tactical changes in completing that strategy, which are important, but having no strategy will go nowhere.
Been part of a team that was very agile and executed quite effectively every day. We just put out fires caused by our bad code. It worked fine in some way every time but hours were wasted but everyone worked hard and gave their best.
I guess a strategy in this context would be post-mortems and root-cause analysis and time for the devs to actually learn the frameworks they are abusing.
Why is this necessary?
The problem is that real life has a way of making your strategy obsolete.
As Mike Tyson said: Everyone has a plan until they get punched in the mouth.
Having a team that communicates effectively and and is agile (in the normal sense of the word) and executes effectively is more important than strategy.