Organizations are not always ready to apply the principle of working without estimates.
In this case, you need to make estimates at least in relative units (story points). In short, people do not know how to evaluate in absolute units, only relatively (similar/more/less). I have seen several semi-scientific articles on this topic, but I have not found them now. You know – send the link.
Many (even developers) do not understand that the principle of story points and velocity is much better than just an estimate in hours. For example, you can read the comments here (I do not recommend reading the article itself): https://habr.com/ru/companies/otus/articles/675026/ .
Further, estimating the complexity of the task and estimating the time for implementation are also different things. Someone from the team is not familiar with the technology, someone with the necessary part of the code, someone has problems interacting with a specific related developer. And we don’t even consider problems with implementation (for example, feeling unwell for a few days).
Yes, many developers are weak (sinful myself) and are ready to give absolute estimates. Only this does not lead to positive results: I have not seen that fans of absolute estimates have at least some adequate accuracy afterwards. As a result, it is rather a sign of unprofessionalism. How else? See the paragraphs above.
So no estimates. In extreme cases, story points and velocity commands. At the very least, absolute estimates, but only for yourself.