I wouldn't be surprised if that author saw or even experienced most or all of what he wrote about. But I have experienced nearly none of it. It seems plausible that Agile/Scrum could be used that horribly.

I'm not an Agile fanboy. Fighting Agile fandom or just making fun of it is not uncommon for me at work. This is an annoying part of Agile in a lot of places, but I tolerate it because I can also use the "fan" aspect to ease adoption of process improvements (and because this and other negative aspects of Agile don't outweigh the positive aspects, IME).

Much of what he wrote is nearly opposite of what I've experienced with Agile. For example, I've never seen the tracking of individual contributor progress used in a way even close to what he describes as the purpose of that. One of the more dramatic benefits I've seen from Agile is the ability to greatly reduce non-direct management's focus on the productivity of individual contributors. The regular, short delivery cycles and several planning elements contribute to Business/Product being able to better predict schedules, which reduces their motivation to micro-manage into within-team concerns.

Most teams I've been on did not even track individual progress nor productivity within Agile most of the time. When it was done, the purpose was simply to counter-act the common problem where a software developer gets "stuck" on a task and repeatedly thinks that they are 90% done while the time spent grows to many times the original estimate. And those times, the point was not even for the team lead to track individual productivity, but to get the developer to realize much more quickly how "stuck" they were so that they would stop trying to "push through" to finish their current approach but instead take a step back and realize a change was needed (I found that swapping tasks with another developer often just solved such problems).

The criticisms that Agile does not cater well to senior developers and long-term projects with significant design requirements and also encourages the build-up of technical debt are more realistic. These are areas where you have to push back against Agile, but even more so, against Agile zealotry. I often laugh when I see again how several of my co-workers who aren't Agile zealots but are Agile fans are just unable to admit that aspects of Agile actually contribute to such problems (insisting that only the mis-application of Agile can be blamed).

But it is certainly not true that Agile makes such problems inevitable. We have Agile zealots here and lots of Agile fans and we have many teams. Most teams have somebody very senior that is very highly appreciated. Many teams have quite successfully taken on projects that took years to develop very complex systems.

My experience is that the really big projects are actually more likely to be successful with Agile than without it. The problems with Agile and large, complex projects are not trivial. But they are less likely to balloon into project killers, IME, than the classic problems that lead to such a high failure rate for large, complex computer projects.

I did leave a previous job, in part, because I was not being successful in pushing for fairly minor process changes to prevent the build-up of technical debt. That was in the context of Agile. But the real problem there was that the person at the top of that company was notably bad at empowering those under him and this attitude rolled down hill. Empowering at the bottom is the single most important principle for success, in my opinion. The people closest to the problem are the ones best able to make good decisions about dealing with the problem. Agile had actually made the tech debt problem less bad than it used to be there. But the tech debt problem in the end was indeed the classic form that can happen with Agile.

One part of the write-up you linked to may reveal a major source of the perspective presented:

Scrum and Agile represent acknowledgement of the idea that emergency powers must sometimes be given to “take-charge” leaders who’ll do whatever they consider necessary to get a job done, leaving debate to happen later.

That is the opposite of empowering at the bottom. In that environment, no set of principles will be able to lead to a good system. I've never seen Agile run in something even close to that manner. And the principles of Agile actually contradict such an approach. Straight from the founding Agile principles we have "Projects are built around motivated individuals, who should be trusted". (I suppose you could misread that as "around motivated leaders, who should not be questioned", but that is not how it was meant and is not how I've ever seen it interpreted.)

So somebody worked in a tyrannical environment where they used many Agile principles and practices. And that was horrible. They also completely rejected one key Agile principle. So such horribleness is certainly not inevitable with Agile. I believe that things being horrible is pretty much assured (eventually) by the tyranny. I see no reason to deny that, in that environment, some Agile principles and/or practices contributed to the horror. But I don't think that actually says much about Agile.