Great question! I think this is a very tough subject to work with because much of "user experience" is subjective, or at least just not quantifiable and thus hard to measure and compare. Also very few good standards for this exists (afaik).
I have a background in UX/HCI but havn't worked with it for ages, so no good examples but just some general thoughts.
I think you have some good ones on your list, but heres a few you may consider to add to it:
a) You criteria should take into account who the end user is, because that will define a lot of whats good or bad design/solutions in relation to your points 1-7. This is subdivided into the users skill with technology in general and the users domain expertise level. Is the end user a novice or expert with tech? Is the user (or rather the primary use-case(s)) for domain experts of domain novices? I think tech-ability is addressed fine by your 7 bullets (at least here on top of my head). The last one about domain expertise is the most interesting one to consider imho.
Here is an example: When we typically say that a user interface has to be user friendly or have good usability or whatever we call it, we picture a GUI with a visual nice design, well organised information, not too much not too little, it is easy to do stuff and so on. But what about the linux sysadmin - is a good interface for him a consistent theme, layout and coloured buttons etc? No, he just wants a terminal interface and great usability to him is if the darn thing is scriptable and supports unix piping input/output (or whatever is sexy to sysadmins).
In genereal you can say that if the user is a domain expert and the use-cases for the application is specialist work, then you want a user interface that is more complex and requires more time to learn -- and that is okay, because the expert user can invest 5-10 hours (or more) of learning the complex interface if it makes him e.g. 25% more productive for all of his tasks for the rest of the years he'll use the system. On the other hand, if the system is a landing page for a SaaS startup, you need to design something that is understandable and usable the target user in just about 20-30 seconds, otherwise he has clicked on. The last example here is a variant of the "domaine novice" situation, and note that it changes little wether the user is tech-novice or tech-guru.
NB: The same user will be a different kind depending on what part of his job he is carrying out (this also goes for non-work scenarios) - the engineer may be happy with a very complex application for his engineering tasks, but the system for handling expenses should be simple (b/c he knows nothing about accounting).
The crucial point is that good usability is very dependent on who the user is and what the use-cases are. And you need to build that into your criteria somehow.
b) I think you may be able to add a criteria on "expectations" - do the system (e.g. a button) do what the user expects it to do? This can be down to colouring and icons: The accept button should be green and not red, the floppydisc icon should save the document, not close it and so on. But there are also more complex things like what the system indicates will happen when the last page of a registration wizard is completed. This is basically Donald Norman kind of stuff I'm thinking about (affordances is the concept he is talking about. sadly became a bit overhyped amongst UX designers but the ideas and principles are great).
c) Last thing and also very important is to consider the context of the system (as in IRL context). If for example you are designing a system for doctors or first responders it will be a key part of "good usability" that you can be interrupted and turn away from the screen a lot, and quickly get back to the task in the system again. The obvious example is if you are automatically logged out after 1 minute of inactivity: If the natural workflow, that the system is part of, simply entails that the user will get interrupted often, getting logged out all the time will make the user stop using the system. In that case the system just needs to adapt to the user's context (so thats part of evaluating if the user interface is good or not).
This was a simple example, but the point is to consider the context of the user and the system, because that will tell you so very much about how the system needs to work to _support_ the user, and that in turn will tell you a lot about the user interface. Context is one thing, but the systems part of the workflow (i.e. the entire job/situation) and things like tacit knowledge quickly becomes very important when looking at this level of usability (and evaluation/review). But that is whole research areas on their own (see e.g. Participatory Design, Computer Support Collaborative Work, Activity Theory, and much more. I'm getting out of touch with academia in this area, so these subjects are probably out-dated by now)