I wonder if Michael has this heuristic there to remind testers to separate business goals from quality goals. So I think purpose is what’s the main use case we “market ourselves” as being best in the market at.
Well, you could ask me. 
The difference between “user desires” and “purpose” is that purpose refers to the designer’ or builders’ explicit or implicit purposes for the product or feature, and that user desires refer to… well, to users’ desires. In other words, one is about the makers’ intentions, and the other is about the users’ intentions and needs— especially the intentions forgotten users. These sets of intentions may not be the same.
As a trivial example, a designer might intend to create an easy-to-use interface (“just click with the mouse!”), but a keyboard user might be bothered or annoyed by having to reach for the mouse.
The difference between “purpose” and “claims” is twofold. First, claims can come from different people, so claims may conflict when people have differing agendas and differing interpretations. Second, the statement of a claim may be different from the intention of the person making the claim — a misinterpretation, or something outright erroneous.
We encounted a problem like this while testing a medical device. There was a specific intention of one of the controls, but the specification had been written by someone not fluent in English — someone who habitually omitted the word “not”. So the specification indicated something directly opposite from the designers’ intentions. This happens, and we must be prepared to notice it.
With respect to the principles and inconsistency: pretty much all of the principles refer to the idea that we want the product to be consistent with desirable things, and inconsistent with undesirable things. “World” is about the idea that the product is typically modelling or representing things in the world. In general, we want the product to be consistent with the way things work in the world. Explainability refers to the idea that we want the produt to be consistent with our ability to explain it. In general, we want the product to be consistent with its own history, etc.
None of these represents a rule though. For instance, we want the product to be inconsistent with its history if there was a bug, and we’ve fixed it. We want the product to be inconsistent with our image if we want to change our image, and so forth.
Although oracles can be used generatively (as Sarah suggests, with her very nice trio of examples) to produce test ideas, they can (and I would argue must) also be used retrospectively. You are more credible when you can explain and justify why you’re suggesting that something you’re observing is a problem.
The point of the oracle principles is that they represent ways for us to recognize a problem when we encounter one in testing. That’s important, because our job isn’t really to create test cases, nor to show that the product can work (that’s a job for marketers or salespeople or TV pitchmen). Our job is to identify ways in which the product might not or does not work. A product can be okay with respect to lots of the principles, but if it’s not okay with respect to even a single principle, we have reason to suspect that there might be a bug, and to report accordingly.
I’m not exactly sure how I’d tease apart “business goals” from “quality goals”, myself. Quality is "value to some person(s) who matter(s). It seems to me that, most of the time, businesses want to produce things that have value for some person(s); and that the business doesn’t want trouble. I would suggest that if you see trouble, whether that’s a problem in the product or a potential problem for the business (or both), report it.
Finally, I’ll end this long reply with this: there’s a serious note on the “you could ask me” stuff above, and that note has relevance for everyday life at work. If someone says something that’s unclear to you, it’s usually a pretty good idea to ask that person what that person meant, since that person is most likely to know what he or she meant.
.