I found this very simplistic, but then I didn't realize it was a checklist for yourself. A few notes, if I may:
first, it is generally recognized that it takes 3 or so tries to get an API/framework correct. Meaning used in 3 or so representative projects. Oh, if you are essentially copying another API in a different language or whatever than the hard work is done. But recognize there will be a lot of refactoring going on in greenfield development. So you probably don't want to do big design up front, as you will get it wrong. Accept that. I'm sure we can point out some genius counter-example, but for us mortals the rules apply.
You touch on some of that in the post, but for me it is always the biggest, most important thing, and it almost always get treated as the elephant in the room that no one really acknowledges, or kind of just hand waves away, and go off and invest 3 months of work into something that is broken and unusable even before public release.
Second, I'm not sure you captured another vital component - that of safety. One of the MS Press books (I forget which one) uses a vending machine analogy. There was a vending machine in the office that had you punch in 2 numbers to get a product. A digit for the row, another for the column. Perfectly usable, except there was endless cursing because inevitably people would punch in the #s in the wrong order, and get something they didn't want. The trivial fix is to use letters for columns, and #s for rows, so the KitKat bar is A3, and the gum is C1. Fixes are often a lot less trivial in code APIs. But you need to design them so the user cannot easily shoot themselves in the foot. How many hours have you struggled with a 3rd party library because it looks like you connected everything up correctly, but nothing works? The API allows you to do things that have no meaning.