A few years ago I changed job and for the first time, I had to participate in estimation meetings. In my previous companies, you were simply assigned a task by the PM and then asked for the estimation. There was no discussion with other devs, there was not even much analysis, it was only just your gut feeling vs PM expectation - mostly it went like this:

PM: "you have this task and we need it in 2 days, what is your estimate?"
You: "Well I believe it is at least one week."
PM: "Mmmm... I see... As I said, we need it in 2 days. I know you can do it! ;-)"

But then finally real estimation meetings: At that time we weren´t playing planning poker. We were sitting in a meeting room with Jira open and we were going through the tickets, then whoever was leading the meeting or often some other experienced dev would throw in his/her estimate - often openly strongly commenting it.

C´mon guys, it´s an easy peasy 3 / S !! Don't you agree?

How could you have the guts to contradict them? You certainly don't want to stand out as the one that is not able to do it, or is afraid of being slower, or sound too pessimistic or point out to senior devs that they might be overlooking some requirements or implementation details. As soon as one said his/her estimate, all other people would follow with very small variations.

Then I joined a team where they did estimates playing poker. I immediately loved it. There was no bias, no fear. If you think something will take lots of time you throw in an 8 Card, or an L ( T-shirt sizes). If it's easy it's a 1 card. You are alone in your decision, you cannot bluff. Then the cards are revealed and you realize that most of your colleagues gave the hard task a 3 and the easy one a 5. Why is that?

People with high estimates and low estimates have to explain their reasons and the real discussion and estimate take place.
Here you discover that the senior dev who had an eagle eye view of the task was not aware of some implementation details making the task harder than it looks, or you find out how over-confident a developer is. Which, btw might be the Dunning-Krueger effect ( basically the opposite of the Imposter Syndrome):

If you don't have the necessary knowledge on a topic you don´t have the meta-competences required to understand your real knowledge
In plain straightforward terms: when we are not good at something, often we are also very bad at judging ourselves and we overestimate our abilities to increase our confidence.
See also Unskilled and unaware of it: How difficulties in recognizing one’s own incompetence lead to inflated self-assessments)

Estimations are more about defining the effort required to complete a task than giving a commitment to when it will be done. This is the hardest concept to grasp at first and even some sort of time mapping will always occur, devs should really try to focus on the HOW HARD rather than the HOW LONG. That´s why with planning poker Fibonacci Numbers or T-shirt sizes are used, instead of hours/days.

Fibonacci numbers:
1, 3, 5, 8, 13
T-shirt sizes:
XS, S, M, L, XL

Let´s leave the conversion to Story Points and than Man-Hours to Project Managers and Agile Coaches!

Btw, in our team we went so far in the abstraction of effort vs time that we had customized Agile Planning Poker Cards with Dinosaurs:

So, to recap, these are the benefits of planning poker:

Avoid the cognitive bias of anchoring

As soon as someone says out loud a number everybody else tends to align with it. Suggestion and influence are too strong. Planning poker you are forced to think independently by having to propose your estimate simultaneously - and then eventually bringing arguments for it.

Facilitate team coordination and discussion of implementation strategies

Team accountability

When everyone gives their estimate independently and the final estimate was discussed and agreed together, this reflects in more overall commitment to on-time delivery.

Fewer towers of knowledge

Who has a lot of knowledge in some parts of the codebase could estimate really low numbers. Having to justify their decision means explaining hidden and cumbersome pieces of the architecture to other team members

More attention to code quality

Over time estimates become more accurate

Especially if comparison retrospective is made: basically after the sprint the team meets again to check the estimates and the effective time spent on the task. Blaming is not the point here, rather reassessing - readjusting everyone´s ability to do estimation and make sure that all members are on the same page when determining amounts of effort.

What do you think about it? Do you play it in your company/team? What is your opinion in general about estimates?

Trivia:

Why those numbers (1 - 3 - 5 - 8 -13 etc) ?
Simply doubling the effort of a task could be misleading. Using the Fibonacci sequence forces you to evaluate precisely each task agains another: A task which is about twice as much effort as a 5, has to be evaluated as either a bit less than double (8) or a bit more than double (13).