I often think of design quality of code in terms of how the creator of that code managed complexity. An oversimplification is to apply a level metaphor like so:

Level 1

Minimally competent. The burden of complexity is placed upon the user. Anything lower than this, and the programmer would have been unable to actually build something that works at all (leaving aside the thornier question of bugginess for a minute). Solution ends up looking like a lot of the stuff posted here.

We've all used (written?) code where its a mine-field of confusion. Click things in the wrong order, the program crashes, you have to read the documentation every time you want to use the library, lots of scaffolding is needed to get it to work at all, etc. The point being, the designer could only manage the solution at all, by foisting a lot of the complexity of the work onto their user.

Level 2

Here complexity is hidden from the user. The interface is well thought out, and reasonably intuitive. However, the code is extremely complex. Here the designer places the burden of managing complexity onto the maintainer of the software.

This doesn't have to be (but often is) messy code. However, the code can be professionally written, and still very hard to understand and change. Truly beautiful and wonderful to use solutions could still be abysmal if you had to go in there and change something.

I surmise that much of the code in regular use is in this category.

Level 3

The interface is simple intuitive etc -- but so is the code itself. Here the designer has taken the burden of complexity on themselves.

Having the time -- and having the skill -- to write clean simple, understandable solutions that also are clean, simple and understandable to use, is (I believe) a rare and wonderful thing. Even if one has the skill, there's not always time to design at this level.

However, I think that for regularly edited and changed software (i.e. much IT software), this level of skill is what's implicitly expected (if rarely gotten) by the customer. Ironically, the time needed is often the first thing that goes as a non-techincal customer can only assess code quality at level 2 designs. Its only later when their stuff can't be changed without major overhaul that they realize there is something wrong. And then the cycle continues...

Summary

I often think in these terms when assessing the quality of a solution -- and when to stop refactoring. I can't say all of my code (or nearly all) meets my standards of Level 3, but this is what I think of as the epitome, the goal to shoot for.

And its what I hope I encounter in other people's code.