Agile is a Sham. Thats SCRUM and TDD and all the rest; it is all those new ways of managing development projects and being super-productive and modern and buzzword-compliant; all the sprints, scrums, playing cards crass commercial nonsense.
1. "Individuals and interactions over processes and tools"
Right there, if you're treating Agile like some sort of process, you're already doing it wrong. Having a process for sprints and when/how/where to have meetings is very much a tax, just like the author points out. It's nice that we have these 15 minute stand-up meetings, but I have stuff to do which I now have to stop doing to listen to people talk about crap that doesn't concerne me (I'm exaggerating slightly, but this is often how I feel during meetings).
2. "Responding to change over following a plan"
But, we're supposed to finish this sprint and we must have 95% test coverage before proceeding and...blah blah blah. Guess what, the customer says they now want this instead and they don't care about your unit tests. I'm not saying you can't write them, but I'm saying sticking to your plan is going to keep you from getting to your goal: shipping software.
I believe in the value of the Agile Manifesto; I try to follow it myself (when it's convenient ;-)), and the company I work for at my day job has been following it since they got started 15 years ago. The key thing is that they don't have a name for it, it's just how things get done. They didn't pay thousands of dollars for some schmuck who's never written a line of code let alone shipped a product to preach to them for a week.
So I don't think the author is dangerously naive, the arguments he's making can easily be applied to the waterfall development process. It was sold as the panacea that cures your development ailments just as Agile is being sold today.
I will disagree with your point about the customer always being right. A team can't perpetually change the product as the wind blows, simply because that's how easily the client changes their mind. I've dealt with clients like that, and it takes a good project manager, as you've mentioned, to know when to say no as well as when to say yes. Sometimes the client knows what they want their software to do (or maybe what they want that day), but not how it can best help them do their job/serve them.
I agree with your statements about Agile's goals, I think that the author probably would too, and I think those charlatans, misguided middle management types, and the crap they shove down are throats they call agile are what he's raging against.
As one of my friends said 'I did contracting work as long as I could withstand how soul sucking it was. And then I had a take a break.'
I also respect teams who follow a well laid out Agile process and thrive as a result; like I mentioned to Bob in my story about code reviews, I wish I could bring more of those facets into our teams. The main problem with all of this is the zealotry (Agile is/is not a sham, etc). I really liked the Steve Yegge post that this article linked to, it's IMO a more refined and carefully worded version of what the author is getting at.