> I'm not advocating for writing sloppy/bad code on purpose
Well, if the “ugly” code works the same as the “pretty” code, but the ugly code can be developed faster than the pretty code, then you should definitely prefer the ugly code: in fact, if this is the case, the ugly code should be considered state-of-the-art because it can be written faster. Since we all accept that the pretty code takes longer, it had better pay for itself in some way. The theory is that the pretty code is easier to maintain over time: it takes longer up front, but when it comes time to make a change, since the code is so maintainable, the change is easier to make. Although that makes intuitive sense, I can’t say that that’s been my experience; in 30 years of software development, I’ve never come across code that’s particularly easier to make changes to than any other. I’ve tried to take maintainability into account when I’m writing code myself, and I can’t even think of a time when I had to make a change and found that my foresight saved me time and effort.
It doesn’t help much that none of us agree on what “good quality” code looks like: everybody seems to call all code “bad”. I’ve I’d like to see software development advance a bit in terms of professionalism where we at least agree on the principles of high-quality software code, and the principles are objectively defensible in terms of what the cost/benefits of following them are.