I'm rather skeptical on this idea that just because a specific feature was never implemented, or just because a specific bug was never fixed, that estimates based on past behavior don't work. That assertion doesn't have any basis on reality. I mean, implementing a feature of fixing a bug is not an isolated event performed with improvised approaches starting from scratch. Teams have processes and procedures that are standardized and take time, and need to be performed sequentially, which means that the improvisation part at best represents a small subset of the time invested working on a ticket.

For a concrete example, let's imagine a team which has a continuous delivery pipeline which involves a code review step and manual acceptance tests. Let's say that the code review can stay in a queue for a couple of hours, or even sleep into the next day, and that the manual acceptance tests require the feature to be deployed to a preprod stage after passing through all unit and integration tests, and that it might take a day to run.

With this process alone, the ticket already takes at least 2 or 3 days between being assigned to someone and being marked as done.

Now, let's say that the coding bit of a random ticket might take 5 minutes or 3 days. This means that the overall time between the start and end time of a ticket is about 4 days +- 2day, which means worse case scenario, it takes 6 days to close a ticket.

How is this sort of estimate not possible?

The problem of providing estimates is not one of predicting the amount of time it takes to close a ticket. The problem of providing estimates is a problem of processes, and how to adequately organize, structure, and classify work. If you don't know what you're doing then you don't know when you're done.