IMO, you need to have the capacity to write Good Code to know what Good Enough Code is. It's highly contextual to a particular problem and season in a codebase's life. One example: ugly code that upholds an architecture that confers conceptual leverage on a problem. Most of the code can operate as if some gnarly problem is solved without having to grapple with it themselves. Think about the virtual memory subsystem of an OS.

The problem with this argument is many do not believe this sort of leverage is possible outside of a select few domains, so we're sort of condemned to stay at a low level of abstraction. We comfort ourselves by saying it is pragmatic.

LLMs target this because the vast, vast majority of code is not written like this, for better or for worse. (It's not a value judgment, it just is.) This is a continuation (couldn't resist) of the trend away from things like SICP. Even the SICP authors admitted programming had become more about experimentation and gluing together ready-made parts than building beautifully layered abstractions which enable programs to just fall out of easily.

I don't agree with the author, BTW. Good code is needed in certain things. It's just a lot of the industry really tries to beat it out of you. That's been the case for awhile. What's different now is that devs themselves are seemingly joining in (or at least, are being perceived to be).