Early on in my career of being a consultant I've came to same realisation. At the end of the day what is a customer going to complain about more, that the code base is spaghetti or that a button is in the wrong place?
The problem is worst in certain sectors. For example I've worked in banks where quick fixes are slapped on top of other quick fixes, often written by other people which creates on monumental pile of spaghetti, not mention they're still using legacy mainframes from 40 years ago. But you have to remember that the customer only cares about money generation, they couldn't give two hoots about the elegancy of your code. But if it works it works.
On the flip-side have worked for startups and I am the CTO of a startup and I can safely say we prioritise speed of features over maintainability and elegancy. We do what we can now but you have to remember that products and its requirements are ever changing and can never be 'perfect'.
Reid Hoffman, the founder of LinkedIn famously said:
'If you are not embarrassed by the first version of your product, you’ve launched too late.'
There is no such thing as perfect code or perfect process, there are spectrums in between. At the end of the day you have to maintain focus on what the customer/users want to see. That's not to say you should roll over for all customer demands, but you should always keep that in the back of your mind.
The other thing is that what you may regard as good code may not be what it others see as good code, it's subjective.
My advice would be if you want to create what you regard to be perfect code then you should work for yourself, whether that's creating your own open source Github repos or trying to start your own company. Otherwise embrace the imperfections of IT and indeed the world we live in see it as challenge to make perfect (too deep? I'll see myself out ...)