There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.
I don't like trying to make direct comparisons between Agile and Waterfall as if they are two separate mutually-exclusive approaches to development.
A product developed in an Agile process still has a 'maintenance phase'; the idea of software maintenance is not a Waterfall concept, it's a Software Development concept.
One thing I think you're having trouble with (maybe) is that this article was about Scrum, but you're attacking Agile. Scrum is an implementation of Agile, or maybe better characterized as a process facilitating Agile development, but it is not uniquely Agile. There are other Agile implementations/processes (Kanban, XP, etc.). Agile is more about attitude than implementation.
What Scrum is attempting to do is break down big ideas into small workable units, and help teams organize, assign, track and complete those work units efficiently. It separates the development cycle into several sprints: a team works a selected amount of items per sprint based on their capacity vs. the 'weight' of those items. If the development process using Scrum incorporates accepting changes to requirements or the design along the way, it's Agile. If it doesn't, Scrum can look a lot like a series of tiny waterfalls; you can absolutely have a Waterfall process where your teams organize and execute work like Scrum.
The most important thing to keep in mind is that neither Agile nor Scrum dictate what you consider to be a finished product, or a successful product. The standard of quality you added to one of your earlier comments is absolutely achievable using Scrum or another Agile process - in fact, it is the stated goal of Agile to turn out a high quality product which meets stated requirements.
The issue is that Agile works far better when you have constantly changing requirements, and when you will constantly work on the code. Agile works best when "development" and "maintenance" are the same. See: Chrome, Android.
Disadvantages: 0 backwards compatibility, annoying for users (I’d love to force the people who made these decisions to try and use a 5 year old Android phone with modern apps, thanks to the constantly breaking APIs that’s not possible), there is no backporting of fixes.
I think we can resolve this debate through a map. I think our problem is a disagreement on what is actually industrialized and predictable vs. What is more exploratory and uncertain.
Most software - but not all - deals with uncertain requirements. These are suited to agile methods.
Other software is in a well understood industrialized domain. Here, I would not recommend waterfall per se, but an approach like Six Sigma and Formal engineering methods certainly makes sense.
A) is how industrialized IoT applications actually are.
It will be 2 decades or more I believe before they are. This will require to lots of disposability and change in the meantime. Hence appropriate for agile.
B) how much indistrialized software will there be in the future? Things like railway systems are well understood and industrialized. And don't need agile. But my point has been there isn't a lot of railway software out there to write anymore.
But at some point, will the newer IoT domains be eventually so industrialized that it requires formal engineering methods? To this I say - sure - but not for a long while. The applications are still too fluid.
C) how many people actually work on various ends of the spectrum of agile vs industrialized ? There has been an explosion of activity in using software in new domains, which is agile by definition. Industrial software even by your own definition only needs to be written once every 80 years. So it makes one surmise it will always be a minority of software development.
Well, whatever Agile means in theory, in practice, it almost always leads to situations like the Android Update situation. Of the Google Chrome Update situation, which is only better because everyone is forced to update.
A situation like the Android update situation, though, is completely unacceptable for smoke detectors or other household devices.
No matter how good predictability is, the demand is that these devices are "buy once, just works™". So we need to write stable software for an unstable use case.
But in no case should we end up with serious devices having a support situation like Android, or the SAMSUNG smart devices.
Yes, it will only be written every few decades, but that is fine. It doesn't need to be a huge industry. Just like Washing Machines are mostly made by smaller enterprises.
I think that the products you're complaining about are in the state they are in because of vendor choices independent of the software development process. If total stability and backwards compatibility are not design requirements, neither Agile nor Waterfall will automatically implement them for you.
I think your class or professors are assigning behaviors and outcomes to development processes that should instead be assigned to the companies or people implementing them.
There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.