So if I'm understanding you correctly, you're saying there's literally no reason for a leader to need to know the details ever unless they don't trust the people implementing the plan. I don't agree with that at all.
Leaders have the option of trusting subordinates, then operating at a higher level. However part of the job of a leader is to decide who to trust, with what. And why.
Sometimes that means, "Trust, but verify." The leader will spot check randomly to see that the whole is good.
Often, as here, that means, "Trust in some things, but not others." The leader in this case trusted the technical person to produce an accurate description of what happened. But didn't trust that same person to arrive at a solution that met the business of having a similar disaster not happen the next time.
But rather than undermine the tech person with, "I don't trust you to meet the business need," the leader communicated it with, "I trust you on the technical details, but here is the expectation for what you need to produce."
Worse it invites bike shedding most of the time, where folks sit in a room nitpicking pointless details that's cathartic for the people in charge, but once again, doesn't actually do anything productive.
The baseline expectation in the original post also applies to the SVP: he knew enough to know that things aren't unreasonable to start with, this expectation might not apply to all companies.
Offloading the detail onto the team allows the org to scale higher by allowing the leader to bring more teams/problems into the mix. But it also introduces the complexity of keeping those teams in close enough alignment that the overall effect is still positive.
This is by no means guaranteed to be positive, and there's a lot of details to get right for leadership in making this work. But they are different details than what each individual team was bringing to leadership.
Abstractions are helpful, in business management as much as in systems architecture.
It seems like you're trying to rebut my argument by presenting my argument as being against a less strong version of the original claim rather than understanding it as being literally just a counterargument to the specific version of the claim I thought was too strong.