This is a poor article on many levels. Even basic facts don't check out.

Agile didn't "grow up in web consulting", and it wasn't about dealing with finicky clients who couldn't be "managed". It came from enterprise both large and small, mostly not involved in web or consulting. In fact, it arguably started before software development did - see Kanban at Toyota.

Agile software development methodologies came from a real need to reduce the failure rate of software projects that was, even 10 years ago, closer to 50% than 0%. It attempted to provide ways to stop the average software project from running nearly 50% over budget. It waged war on the "big design up front" methodology handed to us by other engineering fields and acknowledged that in the real world, software development is often a wicked problem (http://en.wikipedia.org/wiki/Wicked_problem) that cannot be solved until it is solved. It acknowledged that requirements change, and software takes such a long time to build, often by the time a large design is built it already doesn't do what it needs to.

Almost all the statements the author makes are misleading, or misguided.

Violent transparency? It's a good thing that helps software projects succeed.

Atomic little user stories? They embody the divide and conquer philosophy to break down the author's ambiguous "long-term projects" into small chunks that can be understood, tested, and estimated. And delivered quickly.

Shared ownership? Promotes respect of the team, organisation, and customer. Helps get rid of bat-cave developers who can't acknowledge genius other than their own. Helps diffuse any blame for failure.

Social organisation? Has little to do with agile methodologies and a lot to do with the enterprises that implement them. Some do it well, some don't. Scrum doesn't dictate that a product owner or Scrum Master is more important than the engineer. Contoso Shiny Widgets Inc. does that. Just like they dictate whether experience and skill are valuable in their teams, and whether they listen to their engineers about technical issues that cause the kind of technical debt that is hard to solve with "good design".

Exit strategy? Short term? What? Use an agile process when it makes sense. Stop using it when it makes sense. Of course the process is designed to be there forever - they're tools to be used by people trying to solve real problems. The nature of those problems changes over time.

Lack of R&D? Software development is prima facie the D. The R? It's entirely possible to do that in iterations. Agile processes certainly don't remove R&D - spikes are there almost exclusively for R, and they're a first class citizen in the process unlike pre-agile. Perhaps the author refers to those 'long-term' projects that more often than not end up nowhere?

Technical debt? The author doesn't understand agile at all. Agile has two main tools to help manage technical debt - fast feedback loops, and encouraging development in small vertical slices. The best agile has even more - XP promotes TDD, not prematurely optimising, refactor mercilessly among other things. Basically universally accepted ways to improve the quality of software.

Crunch time? No! Agile promotes sustainable pace. To help avoid death marches. Heard of those? They've derailed careers for good.

I'm no big supporter of Scrum - it lacks the software design guidelines of e.g. XP, and it's been abused by some companies for their own purposes (probably those the author has worked for). But it has some fundamentally good ideas, and since Agile methods have been around enterprises small and large have improved on many measurable metrics. It's the best we currently have - come up with something better.