"Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less.
Clean code doesn't mean "no bugs" and "good software":
- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example).
- I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer).
If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead.
The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits.
General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet.
How to make the proper trade-offs? Experience ;).