Such reasoning is based on a flawed assumption: that the value of time is constant in time.
While smooth is indeed fast in the long run, it is slower in the short run, and time before the release date is much, much, much more worthy than time after the deadline.
Shipping functionalities now and bugfixes later is what pays your salary. Waiting for the perfect code makes your customer seek comfort at your competition.
External deadlines are often meaningless, but customers are not the only users of the application. Once you release your part and keep developing/debugging/polishing your code, your colleagues can move on with their job and so on and so on.
As unfortunate and unnatural as this may seem to us programmers, shipping _is_ a feature in professional software development; and, in the quality/time continuum, "something now" beats "all of it tomorrow" in every scenario.
PS: I do get that the decision on releasing a product to the public has different constraints in the medical or aeronautical industry than a photo sharing website, still enabling the rest of the organization to move on with their tasks is too often underrated.
But you still have to put your stuff out there to test it.
All code is a cost. Features are what users pay for. There is scarcely objectively good code. One person’s smooth is another person’s rough.
Deliver stuff. Act on user feedback.
If you are not developing commercial software, the above is invalid advice.