Most of these rules successfully separate gawdawfull code from adequate code. Separating adequate code from good or great code is a lot more difficult.
Separating good from great code is certainly more difficult, but also less necessary.
How do you differentiate a technically proficient painting from a great one, or a decent piano from a great one, or a decent meal from a great one? Rules don't help so much there but we can often sense the difference when we encounter it. Alas the same thing happens with code
I disagree. Part of the reason that experts can distinguish between good and great is because they have a language to discuss the differences with. An amateur may know what they like and don't like but has difficulty describing the what and why of their opinion. To take the piano example, the amateur may be able to tell you that one piano sounds better to them, the expert will be able to talk about the nuances of the sound that make it sound better (harmonic range, sound board reverberation, etc.) Certainly, experts may disagree on the weight to give various aspects of an artistic endeavor, but that doesn't invalidate the process itself.
Likewise, there are aspects of computer code that make one piece of code better than another, the lowest level distinction is, of course, works versus fails. Beyond that there are measures of maintainability, efficiency (O notation), reusability, coupling, cohesion, documentation, etc.
In database design, the ability to add objects or elements without having to rework large swaths of existing code is certainly an aspect of the quality of the design that the beginner often fails to recognize but that the expert does.
--
JimFive