Indeed - but its not that side effects are something we do not want in programming: they are generally speaking the very essence during program execution ;)
True, but I would say that if (thats a BIG if) the code is written to reflect the domain (see Domain-Driven Design), then other developers should be able to pick up the main concepts of the domain pretty quickly. Maybe you have some artefacts leftover from some Event Stomring sessions or a User Story Map or an Impact Map,... all these come in handy.
I agree, Agile is often used as an excuse to not plan anything - which is obviously unprofessional, completely wrong and leads to disaster. I think this was realised by the Agile movement as well, and they have come up with various techniques to also keep track of the long-term aspects e.g. Impact Mapping, User Story Mapping, maybe Event Storming.
True, I am an academic (btw is that something to be ashamed of?), but I have worked 10 years in the industry - and am still doing projects for real clients.
I agree, I could have differentiated a bit more on the How and Why, but I think in the end it applies to both: do the customers REALLY always know what they want? They think so, but it is not really the case. Often it is muddled under a premature idea of a solution the client already thought up. Therefore, its better to start with a minimum viable solution (prototype) so the client actually sees and touches something tangible, which will very often change their idea of what they actually REALLY want.