Although I'm a supporter of using Scrum over anything else in a context where that is feasible, the first paragraph alone illustrates the myopic view of this all-or-nothing attitude.

I mean, I would count myself very lucky if on a given project the only variables defining the problem domain were "technology, requirements and people".

The greatest weakness of Scrum is discounting "change" as a valid characteristic. In many environments sudden, intrusive change interrupting the cozy safety of the Scrum timebox is inevitable. It isn't failure, it isn't incompetence, it isn't mismanagement, it's the reality of the business, and the only way to avoid it is to get out of that business altogether.

And that is the reason why people, no matter how much they like and fully understand Scrum, are inclined to exchange Scrum's power for maybe less effective but more flexible methods.

After all, we don't make money by having successful Sprints. We make money by delivering business value.

"Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution."

imo, this is why Scrum often falls apart in teams, because many teams aren't protected. This devolves into them saying that they are using Agile methodology, when in fact they really are using WTF methodology.