IME agile as an idea has been useful to the industry because it surfaces the difficulties of building complex software to non-technical stakeholders. But it should be a direction rather than a specific recipe.
You're right that we recognised stages and iterations in the past as common sense, before we put a name to it, and it wasn't like everything we did was stupid - but once things like organisation structure came into it (e.g. we'll hire analyst roles and have them capture all the requirements from the customer in a first phase before devs are involved) then it became beyond anyone's individual control. You bring up architects and chefs but these people know roughly what they're constructing in its entirety before they embark on it. Turns out, software engineers and their managers, not so much. And it's way too easy to launch straight into making the wrong kind of software than it is constructing the wrong kind of building, so we get burnt really easily.
The most useful description I ever heard about agile practice was it's like medicine: you take a pill because you need it, not because it's there. Some parts of industry's embrace of it as a buzzword ignores this. I describe what we do as 'small-a agile' because we really don't want to do all the dogmatic manifesto stuff that comes with full-fat Scrum or even Kanban. If I ever hear the words 'planning poker' ever again it'll be too soon. But, short iterations and retro ceremonies and regular delivery are all really helpful. We find and refine what works for us.
Other than waterfall giving you time to form a more coherent idea of what you're aiming to produce, rather than 'let's just build anything', really agile serves us better in almost all respects. But this just means it's comparatively better, not that it's perfect.
You talk about tech debt and yep, this is a problem we face - and short term product delivery is opposed to maintenance, this is very true. But we find ways to mitigate this, like a percentage time allocation to debt, and agile practice actually helps here too - pushing us towards small refactors and improvements rather than huge, how-hard-can-it-be rework projects that get blocked and fail to deliver.
You also identify that software has changed; yes we got systems like version control to help split things up but also sum total complexity grew massively too at the same time. Think how much we depend on libraries and frameworks and continuous deployment now. A lot of traditional practices were not well equipped to deal with this.
I do think we're roughly on the same page here. Amongst other things you're demonstrating critical reasoning and a good understanding of the perils of embracing a methodology too hard. However I think you'd be well served by being cautious around how you express this argument in industry; we as an immature industry went through a lot of collective pain and failure to arrive at where we are now, and there is a lot of distrust reserved for people who seemingly suggest we go backwards. On the other hand there is generally a lot of time and opportunity for people to refine our practices and make them work for us. In the healthiest software organisations, every element of our processes is open to being questioned and altered, so find a way to apply your analysis to those smaller fragments rather than the overarching family of practices like waterfall vs agile.
