The lower bound is quantifiable: if everything goes as expected, and this is all the work, then project time is the sum of each piece's time.
But the upper bound is unknowable. If a thing that we don't know about happens, how long will it take to solve, if a solution is possible? And what portion of the project will it involve?
But that's really a gripe about PMs not understanding compositions of multiple normal distributions.
This would be akin to developers saying "Yeah it only took me 40 hours but it was harder then I thought so pay me for 400."
I can't say for sure, though - I've always gotten very detailed itemized breakdowns of all the cost, hospital stay vs surgeon vs anesthesia vs... but I've never compared them against someone else's bill for the same procedure.
Setting aside the why of the additional expense, the car mechanic model is very similar: you get an estimate, then you get the phone call telling you the additional things they found out, and the new estimate, asking for permission to do or not do the additional things. Though in the case of a surgery where you're knocked out, getting "incremental permission" like that wouldn't really work. You would just have to know the range up front.
But what if the range is so wide to be somewhat useless?
Hospital estimates in the rare case they are provided only seem to get revised in one direction, that seems like having cake and eating it too. If the high school drop out painter can live by his estimates, so can the national hospital chain full of Harvard Business School graduates.
I imagine X here is more of a lower bound than anything else - which is where the problem comes in with up-front pricing.
It's like up-front "how long will this feature take" quotes from developers. Doable, but very difficult to truly accurately estimate.
Doing this on historical data - where the range likely ends up more like .8x to 10x - would be the only sane way, vs trying to come up with it from first principles.