A low-quality codebase slows down everybody on the team and causes tasks that ought to be routine to hit unexpected roadblocks. Every software team has some set of practices for maintaining and improving the quality of their codebase; a few teams, like ØMQ, merge any old crap and then fix the crap (_but not in the backlog_, dear God! _Right away_, before it costs somebody else debugging time) while most teams require that patches meet some kind of quality standards in order to be merged.
By far the fastest I've leveled up my programming skills has been when better programmers looked at my code and told me what was bad about it and what could be improved. You're commenting on the story of someone who offered such commentary and had it rejected.
Word by word this is exactly my experience. Code I was forced to merge was working only on that day in a very limited set of tests. That's not 'working' in my definition. First next feature we needed to add and code would break all over the place. First I was politely telling it can't work because of this and that, then I was fixing the code silently so we don't all hit the roadblock the next day, then I was trying to discuss that we can't really work that way, then I walked away. All in a span of 30 days.
By far the fastest I've leveled up my programming skills has been when better programmers looked at my code and told me what was bad about it and what could be improved. You're commenting on the story of someone who offered such commentary and had it rejected.