Whenever we talk about actual work, there's a tendency of trying to understand how long something will take - or any other proxy metric that means the same thing, but in a more indirect way, such as complexity. This can serve a helpful purpose, but I think it's mostly a distraction. Let's talk about estimations!
For context, imagine a random software engineering team, building things. You have a big thing in front of you, like building a new service or system. As you get more acquainted with the requirements, you start drafting an overall design and soon enough, find yourself in a position where you can actually start implementing things. So you create some smaller units that can be shipped sequentially. Like setting up the service, create the first endpoints, you get the idea. But before you jump into action, someone asks the team to estimate the tasks. As in, put some T-Shirt Size, Fibonacci Number or time unit on them.
Now, there's some really valid reasons for wanting to do that - understanding how much effort building something is is in itself a valuable and helpful data point to decide if something should be done. It's also good to understand, roughly, how long something will take - "it's done when it's done" is not good enough in a lot of business contexts, for better or worse. For me personally, I like to estimate things because I need to understand what I'm building before being able to put a fancy number on it. And I think it can drive constructive conversations on how to build something - kind of like the output of a refinement session.
So a few things that provide value - high level, comparative values used to understand the overall complexity. Use this to understand if you want to build something, but it probably doesn't need a detailed concept, just some folks with relevant background doing a high-level guesstimation. More detailed estimations might be useful to help provide business some timelines on when to expect deliverables, that's also something that can be done on a high level with some accuracy, but depending on the context, a closer look might be warranted. And the third case (that I can come up with) is to actually use it to facilitate a discussion in the team - to lead a refinement and to have a constructive discussion on how to build something. If you know how to build something, you're anyway done with the hardest part of building software: figuring out what to do. Estimating is then relatively easy.
One thing estimations can not do, and should not do, is to enable some form of overly detailed capacity planning for a time unit - mostly a sprint. I've seen this time and time again - folks trying to sequence estimated tasks in smart ways to ensure "capacity is filled". This is about as useless as it gets, and here's why. If you're working on something impactful, that whole thing should be front and center for the team - if it's not, why even bother. If something is anyway in focus, it doesn't matter how long the individual tasks take, since the folks working on it would anyway just pick up the next one once they're done with their current one. There's a natural flow state where the next logical task is being picked up. And once all are done, new work is discovered and found, and that new work can then be picked up. The goal is to build a product, not to follow a too narrow plan that has any free minute planned out already.
What I'm trying to say: Use estimations for high level planning and for creating an understanding of the work. Do not use it to steer or control the actual execution of the work.