I have never seen a ton of value in the exact number of story points, but they are a good way to have the "30 minute debate" that the author decries. If a task is so unclearly written that the team can't get a rough idea of the complexity in a reasonable amount of time, then it's a signal that the story can't be done or that something needs to change; more knowledge sharing, clearer success criteria for the story/task, etc. I get that the meeting is annoying, but not doing the discussion is just going to hide other problems. The longer you hide problems, the more severe they come. Having no idea what the "done" condition is in any of your tickets is tech debt just like long dev cycle times or code that breaks production every time someone touches it; at the project level instead of the code level.
If the only problem is deciding between a 1 or a 2 though, I'd just remove "1" from the list of options.
Not having good definitions of done is also a great way for a team to feel like it's treading water eternally. Small, achievable goals are a hack for team morale. (The trick is making sure that the small, achievable goals roll up into valuable long-term work.)
I think the author was saying the 30 minute debate is a problem when deciding between 1 and 2. 30 minute debate over a "100" might be worthwhile, as long as you're doing it as part of refinement and not during planning.
Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had votes split between 1 and 2 a number of times. That's a 2.
(My planning poker algorithm is:
1. Vote without discussion.
2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13).
3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..."
4. GOTO 1)
This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own.
I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!
If the only problem is deciding between a 1 or a 2 though, I'd just remove "1" from the list of options.