The post is correct about some problems but completely wrong about solutions. Breaking down tasks that are already sub-sprint-sized in a meeting is the wrong way to do it; you'll put the boundaries in the wrong place and end up duplicating work, and then going overtime when the integration stage takes longer than you thought it would. The right place to do that breakdown is agile, just-in-time: give one person or pair/mob responsibility for a piece of user-facing functionality (that they've already agreed is sub-sprint-sized) and let them do whatever breakdown makes sense for that. If they get confused or stuck they can always raise it in standup (that's why we have them!).
Similarly:
> What happens when the team has turnover? What happens a few months down the line when this work comes back up based on the points that were given previously?
Why would you ever put points on it a few months ahead of time? You do estimation in the sprint planning when it's a candidate for that sprint. There's no need to write down the reasoning for the estimation because the estimation is only relevant for the duration of that meeting (as you prioritise stories for that sprint), and maybe in the retrospective two weeks later if the estimate was way off.
I can see the argument for t-shirt sizes. The "queue" idea is the opposite, and has all the problems of point/time estimation.
> When anyone not directly involved with the project asks why it's taking longer than they thought, the answer will be spelled out in the tasks list. These changes were added on these dates, for these reasons based on this feedback from these people. There is no "your estimate was wrong" situation. There is no "re-estimating" process. There's not even an ask to approve if you can change the point value. It just happens.
Guess what? They're going to ask for dates. They're going to ask why the estimate changed, and not care about the answer because they just want to blame you for their estimates being off. And your "tasks" have just become the same time tracking that you were (rightly) scared of; you have the same problem of having to do a bunch of pointless busywork to justify that you were actually working. (Suppose a "task" is suddenly twice as complex as you thought it was; now you've got to file a second "task" with a fake description to justify why you only did 3 tasks this week when Bob did 4).
The problems the article identifies are: spending too much time and effort on estimation, estimating too far in advance (and then having the team and/or circumstances change), and treating estimates as deadlines. These are all real problems. But they're not problems with story points (indeed story points are actively helpful on the last one, since everyone has to at least pretend to admit that story points are not time estimates), and they're just as easy or difficult to solve whether you use story points or something else.