You are correct that most of the IBM provided relevance is overly complicated, but not always needlessly. (though often needlessly)
In general I would not recommend following most of IBM’s relevance as a “Best Practice” for this reason.
The reason this crazy relevance isn’t always needless is to account for VERY old clients that do not have an ability to handle this relevance because they lack the inspectors. The other reason for this is that some inspectors are missing from one OS but exist in another. In a case where the Fixlet/Task should apply to multiple OSes, but you need to write relevance that only works in 1 of the families of OSes, you need to prevent the missing inspectors from throwing an error on all of the other OSes, which will have there own separate relevance statements that would filter them specifically.
This is really a complicated form of relevance to suppress errors.
No matter what you put in the () after then, it will not throw an error: (unless there is a syntax error)
exists TRUE whose(if TRUE then (THIS_SHOULD_THROW_AN_ERROR_BUT_IT_WILL_NOT) else FALSE)
I actually used this technique in a project to do remote relevance evaluation.
parameter "relevance_result" = "{ concatenations "~" of (base64 encode it) of unique values of ( if ( exists true whose (if true then (exists (it as string) of REPLACE_WITH_DESIRED_REMOTE_RELEVANCE_QUERY) else false) ) then (it as string) of (REPLACE_WITH_DESIRED_REMOTE_RELEVANCE_QUERY) else "Error!" ) }"
This parameter will always be set to a string of some kind. It will either be set to the string results of whatever relevance is replaced in the two spots, or with “Error!”.
You can find the full task here: https://github.com/jgstew/remote-relevance/blob/master/Remote_Relevance_Action_TEMPLATE.bes.xml