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.