This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world.
Don't be afraid to dump Scrum.
Scrum adds so much complexity, heavy processes and endless meetings it is truly incredible.
I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc.
Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood.
(Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.
Waterfall has the following 5 requirements/steps:
1. Design first. It'll get replaced (see step 3), but is needed for requirement 2.
2. Document the design. This defines what you're building (this time around) and the tests.
3. Do it twice (build a MVP, test, refactor & replace it as requirements become clear based on customer feedback, update the design & docs & tests, use those tests for the improved version).
4. Plan, control, and monitor testing.
5. Involve the customer.
Requirement 3 is what makes Waterfall inherently an incremental iterative process.
That's my experience also. Since the early 80's, every project I've been involved in was managed with a semi-flexible, pragmatic approach that involved breaking down the problem into smaller chunks, regular communication with the customer, etc.