Ah, another Dunning-kruger-bait post (someone who doesn't know what they're talking about who writes a blog post very confidently, and it's read and upvoted by people who also don't know what they're talking about). Very good.
The immediate pooh-poohing of Waterfall is the big tell here. If they don't give you an example of an actual Waterfall project they've worked on, or can't elucidate why it wasn't just that one project or organization that made Waterfall bad, they're likely parroting myths or a single anecdotal experience. And that bad experience was likely based on not understanding it to begin with (Waterfall in particular is the subject of many myths and lies). I've had terrible Agile experiences. Does that make Agile terrible?
In my experience, Agile has a tendency to succeed despite itself. Since you don't do planning, you just write one bit at a time. But of course eventually this doesn't work, so you spend more time rearchitecting, rewriting, and fixing things. But hey, look, you made something useful! ....it still isn't making the company any money yet, but it's a thing you can see, so everyone feels better. You can largely do this work by yourself, so you can move fast; until you need something controlled by someone else, at which point you show up at the 11th hour, and dump a demand on their desk that must be finished immediately. Often these recipients have no choice, because the organization needs the thing you're slapping together, and they're "being a blocker". And those recipients then can't accomplish what they need to, because they haven't been given any documentation to know what to do. Bugs, rushed deadlines (or worse, no deadlines), dead-cats-over-the-wall, wasted effort, dysfunction. Is this the only way to do Agile? Of course not. But it's easy for me to paint the entire model this way, based on my experience.
There does not exist a project management method which is inherently bad. I repeat: No formal project management method is bad. Methods are simply frameworks by which you organize and execute work. You will not be successful just because you used a framework. You still have to do the organizing and execute the work in a not-terrible-way. You have a lot of wiggle room about how things are done, and that is what determines the outcome. You can do things quickly or slow, skillfully or shoddily, half-assed or competently, individually or collaboratively. It's how you take each step, not which step you take.
As long as humans at at the reigns, it doesn't matter what method you use. The same project, with the same method, can either go to shit, or turn out great. The difference between the two is how you use the methods. You have to do the work, and do it well. In organizations, with other humans, that's often very difficult, because it means you depend on something outside of your control. So leadership, skill, and a collaborative, positive culture, are critical to getting things done.