What makes agile / scrum different from other projects is the constrained timeline. It's 1 week to delivery. Then, you get feedback and plan all over again. The major drawback to this approach is that some projects (including many software projects) are impossible to fit into a short schedule. The big benefit is, when Scrum is possible, the rapid iteration allows for products and services that are truly tailored to the user's / company's needs today, and not their needs six months ago.
I recall having a code-review conversation with a co-worker that ended with him saying roughly "I can see your case for (minor change that dovetails with the change he was working on) but it's already the second Thursday of the sprint."
I've also seen the organization complaining "we want 90-110% predictability of points delivered". I know the intent might be to encourage people to get more accurate estimates, but there are upper bounds on estimate quality, especially for tasks where it's "30 minutes of coding, and between 1 and 62 days of negotiating details with a third party to get signoff."
The takeaway I get is that Scrum basically says the most important thing is to produce a predictable quantity of work, not necessarily that the work is good or fits the actual need. It reeks of the sort of metric Wall Street would love-- I can see someone saying "Story Points/Quarter Line is going up!" ebulliently.
Producing work that fits the need should be the goal even if it means delivering fewer points of work during a sprint. Of course, like you said, the focus is often the other way around because the policy sucks.
"You need to get this project done in 6 weeks, but because we are agile, you can choose which parts you implement during the first 3 weeks, and which parts during the second 3 weeks. Also, I am not really sure about the specification, and some important parts may change halfway, but that's okay because you guys are agile, right?"
Basically, agile was supposed to mean "project deadlines are unpredictable, let's just focus on the tasks we are currently doing (Kanban) or let's focus on one increment at a time (Scrum)", but instead it means "you are responsible for meeting the deadline, but I am not giving you the full specification at the beginning, and instead will just tell you the requirements at random moments when they come to my mind".
EDIT:
Some parts of this article are just triggering to read.
> Cons of Scrum: Resistance to Change Mid-Sprint: Scrum's framework can be rigid within a sprint, and any changes occurring within the sprint could disrupt the team's flow.
Translated to plain English: Some companies change their mind about the product so often that they are literally unable to plan even for the following 2 or 3 weeks.
> Dependence on Stand-Ups and Meetings: Scrum can be meeting-heavy which could potentially lower productivity if not managed correctly.
Stand-up done properly takes 5 minutes. What other heavy meetings are we talking about? The retrospective and planning that happen once in 3 weeks? Any meeting on top of that is a part of your company culture, not Scrum.
> Not Ideal For Solo Workers: If the team is too small or primarily consists of independent workers, Scrum’s benefits may be less noticeable.
Even as a solo worker, to be told what needs to be done during the following 3 weeks, and then to be left alone during those 3 weeks, would probably be a huge improvement for many.
Yes, everything has cost, timeline, and quality requirements, but the way they are represented or discussed vary a fair bit.