Kinda. Except that's "need for a definite date" is an expectation that they could be flexible about if forced. If other professions genuinely understood that software estimation is inaccurate by its nature and that accurate predictions of completion dates are, by their nature, impossible, then the uncertainty can be managed.
But because it seems so simple to estimate how long a piece of work will take for everyone else, it's really difficult to get other people to realise how hard this is.
I've sat in meetings saying "I don't know how long this is going to take" repeatedly until the rest of the organisation works out that they're not going to get a definitive date. Then suddenly the marketing team plans for "OK, well if it's done by this date then we'll have enough time to make this trade fair. If not then we can skip that and do the other one". They'd like to have a definite date because it makes their job easier. But if they can't have one, they can work around it.
> I also believe that a feature request is incomplete without an xestimatex delivery date attached
This is so true, as long as the devs have control over the scope. "We don't know and can't predict how long it's going to take to build the thing. If we can't build it all by the deadline, what's more important: delivering something on the deadline, or missing the deadline and delivering the entire feature set?"
To use your car haggling analogy: You've given me $5K to buy a 4-door car less than 5 years old. If I can't find one like that, what's more important: the budget, the doors or the age?