"Perfect is the enemy of good" is an adage attributed to Voltaire. It's certainly appropriate that a philosopher with concerns of aesthetics and quality should advance the idea. After all, nothing is ever perfect, and if you insist on only having what is perfect, you won't have anything at all.
The reality of this was made clear to me working for Space Industries, a company that wanted to manufacture semiconductors in low Earth orbit. This was the 90's, and to get their manufacturing platform to low earth orbit, they were sending it up on NASA's Space Shuttle.
Getting a payload on the Shuttle was not the same as shipping a box, there were safety reviews, vibration tests, functional tests, and space requirements all set on rigid, predetermined dates. The lead engineer was incessantly reminding the team that perfection was not a consideration, good was the measure. Make the required functionality work reliably in the most efficient manner possible and move on. Missing any review or test date would result in losing the flight slot. Pursuing any unnecessary, self-imposed requirement could result in a loss of the whole program.
Most projects don't have hard deadlines that result in binary success or failure, but all products are subject to the diminishing returns of additional features. Chasing perfection in practice means focusing on ever finer details in ever more elaborate features. Ultimately, some of these features and details won't make an impact for the customer, yet they will take resources to produce.
If you produce a good product that has demonstrable customer value, then you can mark a success. On the other hand, if you wait to produce a "better" product, you can't score a success, and you're at risk of wasting resources on valueless features or optimizations.
The worst thing that happens if you deliver a good product is that the customer asks for more features that makes them even more productive. And then you can build good versions of those features! By building what customers need, when they need them, you can avoid diminishing returns and continuously deliver new value.
Procrastination by Any Other Name
Finally, perfect, and even better, can be excuses for not delivering anything. It's always easier to have another meeting to discuss the solutions to hypothetical problems that will be solved with a new feature than to actually build and deliver something.
And this process can go on at every level. Make sure the feature design is just right before writing any code. Make sure the wire frames and UI mock-ups are just right before doing any technical design. Make sure the architecture can scale to 1000's of users before you have any users.
The lazy and easily distracted can find myriad ways to avoid actual work in the name of the higher calling of ever better solutions.
The reality of great software, products that might seem to deserve the label of perfect, is that it results not from a dithering pursuit of perfection, but from the steady refinement of good products based on the feedback of active and engaged users by teams that truly understand that all software that works is better than all software that doesn't.