I stated the opposite of that — customers are not expected to know the technical aspects, and the problem lies elsewhere.

“Customers are, in general, very poorly placed to know what is reasonable in a software project timeline. How is a non-technical customer meant to know what a reasonable timeframe is for a given feature, or how a certain feature should be implemented?”

This paragraph doesn’t blame customers — it blames incompetent managers who act against a customer’s own best interests. In many businesses, not only software, sales reps or managers will agree to customer demands even if it’s not in the best interests of the customer, to make the customer *think* they are getting exactly what they need or want. This often means managers won’t explain to the customer why their request is a bad idea and what the better alternative is, which *especially* in software leads to very bad long-term outcomes (as customers often want things done as fast and as easily as possible, which in software doesn’t go hand-in-hand with well maintained or designed code).

The management problem that you mention — of agreeing to unrealistic timeframes etc — is directly exacerbated by Agile, specifically due to the “customer collaboration over contract negotiation” part of the manifesto, which in real life translates to managers being much more ready to agree to customer demands rather than actually stand their ground when it isn’t the best technical decision. This also tends to mean that in order to avoid seeming non-compliant to customer demands, actually explaining technical issues with a particular request isn’t encouraged.

In addition, Agile’s “responding to change” strategy usually translates to constantly changing project requirements at the customer’s whim whilst being far less likely to contest them or explain why they are bad ideas.