First off, Agile isn't a software development methodology, its a set of principles for an organization to apply in selecting/developing in its own software development methodology (you could call it a software development metamethodology.) Scrum is more of a methodology (and, while it may have emerged from the people involved applying Agile principles in the context in which Scrum was developed, and has features designed to support use in an organization applying Agile principles, there is nothing
fundamentally Agile about Scrum -- or any other development methodology; if some decisionmaker is sold on Scrum by some consultants and adopts it as a top down practice, that organization may be doing Scrum, but they aren't doing Agile -- in fact, they are doing exactly the thing that Agile is a reaction
against.) Almost any time someone uses the phrase "Agile/Scrum" they either mean Scrum or something that is neither Agile nor Scrum. In this case, the criticism seems to be of something that is neither Agile nor Scrum, though it may be
related to the latter (but not at all the former.)
As to the specific points:
1. Here, the claim is: There is no place for an actual senior engineer on a Scrum team. The only way to move up is to become a "Scrum Master", a bullshit management role that involves responsibility without power.
There are several errors in this description: First, "Scrum Master" isn't management role, its a facilitation role focusing on expertise with making Scrum work in the particular organization. The only quasi-management role on (or related to) a Scrum team defined in the Scrum Guide [0] is the Product Owner (which does have authority to go with that responsibility.) Either of those is a role a team member could develop into; the idea that the SM role is the only "way up" on a Scrum team is incorrect even within the narrow bounds that are defined by Scrum.
OTOH, Scrum itself intentionally -- to support its use in organizations using Agile practices -- defines only a narrow slice of practice, particularly, a basic model for operation of individual development teams. It does not prevent having different roles outside of the defined interactions within the Scrum guide for members of different seniorities or specialties, it only requires that for the purposes of the interactions it defines, only a narrow set of roles ("Team Member", "Product Owner", "Scrum Master") matter. So, consistent with Scrum, there can be room for moving up on a team. And real organizations using Scrum on projects greater than a single 3-9 member team use complementary practices like the Scrum of Scrums [1]; being a Scrum team's representative on the Scrum of Scrums and thus playing a larger role in the coordination of the overall work of the project is one way for a technical contributor on a Scrum team to move into a role with
broader scope and exposure.
2. Here, the claim is "It's aggressively short-term, by design" and "if you carry this way of working on for months or years, you get a lot of technical debt and you get low morale."
It is certainly the case that Scrum, specifically, largely addresses tactical-level, short-term processes. This is because Scrum isn't a full-stack methodology, its a narrow set of practices designed to adopted as part of a larger set in an organization working in an Agile manner, and to be relatively neutral to the other practices. Certainly, if you apply Scrum alone with no higher-level strategic processes that set standards that constrain the definitions of "done" for work done in sprints to avoid technical debt, there is a lot of potential for an organization applying only what is in the Scrum guide to lack long-term focus and development technical debt.
3. The claim here is "It has no regard for the programmers' career needs or desires."
Agile, as a set of principles, certainly does; Scrum, as a particular set of practices, does not, for much the same reason addressed in the previous point. Largely, though, this seems to be a restatement or alleged further consequence of the first complaint about lack of a way to move up (it essentially seems to be, "because of #1, Scrum leaves me nothing interesting to put on my resume"), and so the response to the first complaint above largely addresses it.
4. There's a lot here that deserves separate responses, so I'm going to break this one up.
> "It's micromanagement."
No, Scrum is the opposite of micromanagement, since the "management" is done almost entirely by the team.
> "User stories and backlog grooming are there to control what the engineer works on."
Sure, those things exist to define work, but they are done by the team, so can hardly be viewed as micromanagement of the team.
> "The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking."
Scrum defines four kinds of meetings: the Sprint Planning meeting, the Daily Scrum, the Sprint Retrospective, and the Sprint Review. Of them, the Sprint Review is the closest thing to a "status meeting", though even their the focus is demonstrating the concrete deliverables for the Sprint rather than status reporting. All of the rest are primarily action/planning meetings. "Status" of a sort plays a role in those meetings as an input to the planning aspect, but if they become status-focused meetings rather than planning-focused, you've definitely lost the defined purpose of the meetings in the Scrum guide.
> "The story points are there to track productivity (in some superficial, inaccurate way)."
Story points (in methodologies where they are used; they aren't part of Scrum) exist as a planning tool for the team, not a productivity measure.
5. The claim here is "At identifying low performers, it has an unacceptably high false-positive rate."
Scrum (and, a fortiori, Agile) is not a process for identifying low performers, or for performance evaluation at all -- its completely out of scope. Its not that it is good or bad at it, it doesn't even address the issue.
6. The claim here is "It punishes R&D, and it hurts the best engineers the most" because "Agile and Scrum [...] single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it."
Research is a separate domain than product development, and there is no reason that the use of Scrum as a product development methodology should have any impact on how research is done. Of course, Scrum is a generic enough process that you could use it to manage research efforts as well, but the backlog items, associated definition of "done" for those items, sprint length, etc., would all likely be very different for a research effort than a product development effort. You could mix research items into the backlog of a team also doing product development, but then you probably have a problem defining work items that are appropriate for the product development sprint length. (This is less of a problem for non-Scrum methods that use a flow method for backlog management rather than a timeboxed Sprint cycle, because then its easier to mix items that have a longer-than-usual time involvement into the same backlog; the sprints used in Scrum place an effective upper bound on the size of work items.)
7. The complaint here is "I have actually seen it kill companies" backed by a single non-specific anecdote and the assertion that it generalizes. From the description, this appears to be a top-down all-at-once conversion to a new defined methodology. If one has processes in place, for the same reason one adopts incremental change to a software system where you've got an existing, functional system unless there is some reason you can't do incremenetal change, the same thing should be done to a software development organization. Failure of an organization (or many organizations) to manage a big-bang change rather than incremental change doesn't invalidate the methodology they sought to change to any more than failure of an organization to manage a big-bang software system replacement invalidates the technology they sought to change to.
[0] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US...
[1] https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrec...