"No, it's less effort than that"

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.