Interesting distinction to reflect on. James and Uncle Bob seem to be using "exceptional" slightly differently.
I think my own practice is driven by whether I consider a case to be in or out of the contract for the class. I start with the simplest cases that fall within the contract (empty inputs, maybe nulls, etc.), then proceed to more interesting cases that flesh out the contract. Only then do I worry about how the code handles cases outside its contract, such as malformed inputs, and often I don't bother if the code in question isn't a public API of the system.
Some cases that Uncle Bob calls "exceptional", such as deleting an element that doesn't exist or adding a duplicate element, don't sound so "exceptional" to me -- they're interesting cases within the contract, but not the simplest ones, and therefore feel like "grabbing for the gold" if I do them first.
And some cases that he calls "exceptional" seem potentially quite hairy, and therefore inappropriate to start with, since handling them nicely can often get complicated -- e.g. giving a nice diagnostic error message may require parsing as much of the input as possible, which can be much more complicated than parsing the input assuming there are no errors.