First, an operational definition: Kanban as it's used in lean software development is 1. visual representation of the work that's in the system and what state it is in and 2. an opportunity to limit the amount of work that can be in each state.
That's it.
Almost every organization that writes software uses something to keep track of the work, and what state it is in - by this logic the title of the article could be "spreadsheets - the secret engineer killer", or "JIRA - the secret engineer killer".
According to the article though, Kanban is ruining engineering teams in "nearly every company" that has adopted Kanban out of the 150 companies the author talked to in the last 60 days. (Some numbers on how many of them are using Kanban, and for how long, would have been nice facts to include, btw.)
So, let's unpack some reasons why this is:
"Engineers are not assembly line workers" - Implying Kanban and pull-based systems only work for "widget producers" and forces engineers to focus on the individual trees, not the forest. I think this sort of highlights the author's misunderstanding of Kanban (and to an extent any pull-based system) and what role it serves in an organization. Kanban isn't magic - it not an organizational design, it's not a product development strategy, and it's definitely not a substitute for leadership. It's a chart on a wall that shows what the work of the product development organization looks like, right now.
For an example of an overall software product development strategy that incorporates pull-based systems as one component, I recommend checking out "Principles of Product Development Flow" by Don Reinertsen.
"It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects." - How does it do this? Nothing about Kanban implies no estimates. In fact if you use Kanban and measure cycle time, you will be doing evidence-based scheduling which will allow you to make better estimates. As for "complex multi-faceted projects" - I don't know what the author is talking about. Please read "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde for some actual evidence and lessons learned on lean / agile approaches being used on huge software projects. Also "Scaling Agile at Spotify" by Henrik Kniberg is worth a read, as Kanban features there (by team choice!) as one small component in a lean software development org design / product development strategy.
"Kanban forces a 'one work item at a time' mentality and resists milestones." This is simply not true and such a basic misunderstanding I have to wonder if the author of the article has taken the time to read any of the introductory literature. If not, I suggest the aptly titled "Kanban" by David J. Anderson. Kanban wants you to limit work in progress, which is one of the basic goals of any product development system. It doesn't say how much it should be limited, or where it should be limited. Every system, everywhere, already has limited-WIP in the form of bottlenecks. The hopeful goal of pull-based systems in general and lean software development specifically is that you'll use these simple tools to look at your process and eliminate wasteful activities and streamline those bottlenecks that must exist to deliver maximum value to your customers. In this sense, you can use Kanban as a tool to maximize the whole of the product development process which is certainly a macro (org level) goal and outcome that stands in stark contrast to the claims in the article that Kanban in general promotes micro optimizations and misses the big picture.
For more general reading on why limiting work in progress is a good idea, I suggest "The Goal" by Eli Goldratt or more recently "The Phoenix Project" by Gene Kim. As far as milestones go, nothing in a pull-based system is incompatible with milestones of fixed date or fixed scope. If your idea of milestones is chucking arbitrary dates on a calendar based on an estimate before work begins and then stubbornly refusing to adapt those milestones when the situation on the ground changes (i.e. milestones of fixed date and fixed scope), then I could see the potential nature for conflict, but surely you're not out there doing that in real life, right? (Right???) If you are, and that's the issue - Kanban isn't the problem, the problem is the assumptions you are operating on are faulty - nothing will work for you. Smarter folks than me have written about the perils of fixed date and fixed scope development, I suggest googling for Neil Killick's thoughts on the matter.
"High performance individuals and companies are goal and date driven." Citation needed. I know many people really, really believe this but you should really verify. Also, see Fred Brooks "Mythical Man Month".
"Kanban was never intended for software development" - What? Again, the guy you quote actually wrote a book on using Kanban with software development teams. You should read it, as it would probably correct 90% of the misunderstandings in your article.
Those are the key arguments in the article about why Kanban is "the secret engineer killer". Hopefully by now it's clear that these arguments aren't very good and it certainly wasn't any trouble for me to refute them along with a bibliography for further reading. That doesn't mean Kanban or lean are perfect though - there still is no silver bullet. Hopefully this inspires some folks to launch a more throughly-researched critique of lean, kanban, or pull-based systems in the future as I think that kind of discussion can be really beneficial.