I think people don't understand the reason and given flexibility tend to choose completely counterproductive things to do.
For example the only purpose for points and velocity is to give product owner idea of how much time will have to pass before a thing might even have a chance of being done. It tells him that you, for sure won't get this thing and that thing in next 2 weeks.
The only utility of points for the developers is when doing planning poker. If something gets a lot of points then this means people are not sure how to do it and the thing needs to be discussed and broken down.
After that, points have no use for the team and team shouldn't even be aware of its velocity and how much they burned so far this sprint. Those are the tools just for the product owner and scrum master.
If product owner is satisfied with "it's going to be ready when it's going to be ready" then points after planning poker can be forgotten and you don't even need to calculate velocity. It's still worth to do the planning poker for the sake of the team discussion and so the product owner can deprioritize task that are hard but not crucial.
But turning points and velocity and performance measure is dumbest thing you can get, because then it get's screwed and loses all utility. Same thing in estimations. If manager is going to negotiate estimates then you can as well not do it at all because they no longer carry any real information and are becoming just the reflection of managers hope slightly skewed towards developers hope (which was already overly optimistic).
And velocity is not comparable between teams, because different teams will normalize their complexity points differently. The amount of complexity points that any type of task is given, is supposed to be emergent in that team, because this makes a team's optimism/pessimism bias moot. The reason to use complexily points and not time estimates is also exactly this - to remove preconceived anchoring.
I wish I could highlight this a million times over. The idea of story points (which I have mixed feelings about regardless, but are not as bad as the author of the article mentions) is to produce a useful measure, which becomes instantly useless once it becomes a target. Once you start saying that you have to meet a certain velocity, you've gone off the rails.
For example the only purpose for points and velocity is to give product owner idea of how much time will have to pass before a thing might even have a chance of being done. It tells him that you, for sure won't get this thing and that thing in next 2 weeks.
The only utility of points for the developers is when doing planning poker. If something gets a lot of points then this means people are not sure how to do it and the thing needs to be discussed and broken down.
After that, points have no use for the team and team shouldn't even be aware of its velocity and how much they burned so far this sprint. Those are the tools just for the product owner and scrum master.
If product owner is satisfied with "it's going to be ready when it's going to be ready" then points after planning poker can be forgotten and you don't even need to calculate velocity. It's still worth to do the planning poker for the sake of the team discussion and so the product owner can deprioritize task that are hard but not crucial.
But turning points and velocity and performance measure is dumbest thing you can get, because then it get's screwed and loses all utility. Same thing in estimations. If manager is going to negotiate estimates then you can as well not do it at all because they no longer carry any real information and are becoming just the reflection of managers hope slightly skewed towards developers hope (which was already overly optimistic).