Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
If you're a developer who throws code together in a few months for clients who aren't paying for a quality product, and maybe you'll come back to it a couple of times in the future when it needs a new field added or a page title changed, then a hack is perfectly valid and can hugely improve your business's bottom line over spending even just another 10% making sure you've got tests and documentation and defensive code and so on. Spending time on the maintainability of code that no one will ever maintain is a waste of time.
This has been a major point of contention for us recently with team members that can't distinguish 'urgent' matters from 'important' ones.