Should developers stop estimating their tickets?

Pointing stories/tickets/units-of-work should not be tied to time estimates [0]. It should be a tool to break down useful deliverables into the smallest useful deliverable, leading to less unknowns. Example: a task of "move application from vm to kubernetes" could be reduced to smaller parts that give the business greater insight into its progress. Maybe you have to get it working in docker first, maybe update the integration test environment, update the build pipeline, and maybe have a roll out strategy. Maybe any of those need to be finer grain. The pointing of the original story might show that the story is large and it can lead a discussion on breaking it down. Again, this is all to provide visibility to the business side. It gives them more confidence in you and your team compared to "we are still working on it."

[0]: if your team trends to a consistent velocity of points, it can be tempting to start equating points to time. Avoid this.

The reality is the business needs estimates for a couple of reasons. Prioritization (which features do we work on), resource planning (if I want to get x done in the next 6 months how many devs do I need), client communication (when will very important feature X be delivered). And no amount of organizational dysfunction will change that.

One of the biggest issues is that commitment dates and probably take this long i.e. prioritization times get muddled. And the possible solutions are buffer your prioritization times to turn them into commitment times or be explicit with the business about that.

I wrote this tool for uncertain estimations: https://uncertain.io/