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.
.