The argument that you can absorb technical debt only really works if you plan on an aquihire to save yourself, because if not it's very likely you'll have to clean it up (and you'll have paid a decent amount of interest on it).
It's not like good code and code that's easy to write are two ends of a line.
Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually all the "yeah, we should have thought about that before" remarks are just that. You wouldn't have thought about it before, because you need the scars to tell you "Bad idea, don't do it again."
How many bug incidents were there ?
How many times did a design decision have to be refactored out ?
How many times did you really have a problem ?
Then, first things first, take out all problems that were obviously not project related. The team moved ? Someone went on holiday ? All of those don't matter.
After that, you'll have problems left. If it's 3 problems, none of which delayed more than 2 weeks/10%, your project went as well as you can reasonably expect. Don't change a thing. If after that you arrive at the conclusion that the project went ~80% as planned, then you've simply done it right. There are no lessons to be drawn from mistakes, because the fixes are likely to screw you up more than the "mistakes".
Even when this is not the case, you should limit fixes. Take the top-3 problems, at the very most, and implement a fix for one of them. Then try to mitigate the second and stay away from everything else.
If you don't you'll have seriously more regrets about your next project a whole than your current project.
Lots of people generally don't do this. They do a project, then switch programming languages. That's a decision you should make once in 5 years (unless you're switching back after a disappointment). People seriously overcompensate. From management to developers. Redesigning an entire organisation because one bad apple leaked something is very likely not justified, and similarly a rewrite is almost never justified.
Figuring out when something is too simple is trickier, but it tends to be pretty obvious because a ton of bugs come in that are easy to locate.
Over the past few years, I've decided that as a general rule I prefer engineers that under-architect to those that take it too far, because the damage is far easier to mitigate...