That's orthogonal to what the parent was talking about.
You can't just say "I bill by the day" until the MVP is complete. Whoever is contracting you out will want a ceiling on how many days it's going to take. They don't have unlimited money or time. And once you give them that initial number of days for the MVP, congrats, you just made an estimate.
If the MVP is truly an MVP and the client isn't chronically short of cash it should be at least an order of magnitude below what their initial budget is.
I tend to find that when a strong emphasis is put on estimates it's because:
* The client simply can't conceive of reality in a non-waterfall way. This extremely common, but, in which case they're putting themselves at a competitive disadvantage in the software business to those who can. If you've ever wondered why big business can enter the tech market and spend 100x as much as a scrappy startup and still get completely thrashed in the marketplace, well, this is a large part of why.
* There has been some breach of trust.
Unfortunately, I find a breach of trust caused by missed estimates tends to spiral into an even greater emphasis on estimates in a kind of negative feedback loop ending with big balls of mud, stressed developers, development velocity that grinds to a halt, buggy releases, etc.
On the other hand, you can cause a positive feedback of trust and decreased reliance on estimates by delivering reliably.