"No, it's less effort than that"

I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building.

A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.

In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.

In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).

Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.

> Engineers have a habit of over engineering

Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely.

Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.