Everyone understands that why the business needs to an estimate and that shorter is better than longer. There is no ambiguity there at all. The complaint is the phrasing like the developer can know when it'll be finished. Someone's ability to deliver value quickly is unrelated to their ability to estimate how long it will take. They can get their estimate completely wrong and deliver huge value. And we all know if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators for the same reason that software companies often develop product teams to negotiate what features a product should support. There is no point asking devs to do it. Oh course, no-one else can either and the devs will at least get the lower bound right so people bother them but the process is transparently stupid.

To know how long something will take it is necessary to list all the steps taken to do the thing. That just isn't possible in software development. Developers can come up with a lower bound for a given set of requirements. And I think everyone agrees that they could do an accurate estimate assuming nothing unexpected happens. Then, in 95-98% of projects, the estimate turns out to be under-calling how long a project will take. The "developer estimates" becomes a measure of how much fat the developer feels like putting in the system this project.

Asking for estimates completely misframes the conversation. The question is what problems does the business have now, what problems are likely to develop in 6 months, and some input from the developer on the cost-benefit of trying to solve those problems. Then people make some qualitative decisions with an eye on minimising risk. The best outcome after giving software estimates is that everyone ignores and forgets them - anything else destroys business value.