You're really asking if a user would want a program that fails a fifth of the times?

In some cases it might be better to have some crap right away and more cheaply, but even you would probably not like a 20% failure rate in most of the software you use.

That would depend on who your users are and what they're using their program for. My point is that the context of who is using the program, how they're using it, and what they're using it for are what actually matters, because most of the time, software that no one uses is by definition useless. There are circumstances where that might not apply, like code used as part of education or training (whether in a formal course or a project someone writes specifically because they're trying to learn something from the process) or when the purpose is aesthetic or humorous, but I'd argue that whatever process makes sense for them doesn't necessarily bear any resemblance given how different the goals are.

Try this argument in any field where the stakes are high (e.g. medical diagnostics) and see how far this gets you.

This is really basic decision-theory stuff, often the cost of an error is far greater than the benefit of correctness.