Be sure to read up on ACVAR before you use them too much.
There are different types of ACVAR. If you're not using one of the ACVAR of the 'built-in' type, then they need to be defined on the endpoint in some manner before they can be used. The 'built-in' type are predefined and populated by ControlMinder (for example, USER_OS_ADMIN you listed is a 'built-in' type and will resolve the default administrative account on the endpoint.. typically root on UNIX/Linux and Administrator on Windows, but I know that on Windows at least it will detect if that account name has been changed to some other non-default value (a common security practice)). The ACVAR of 'osvar' type will pull the value from the host's environment variables. The 'regval' type on Windows will take the value from a registry variable. The 'static' type (which is default type if no type is specified) will require an explicit command to set the value (either via selang or policy).
The ACVAR values can be useful, for example, if you want to create policies for an application using FILE or PROGRAM rules but that application is not installed in the same location on every server. However, it adds complexity because the variable needs to be set before it can be used. If you have policy verification enabled, or if you don't use policy verification but dislike receiving 'deployed with failures' status on policies then this is pretty painful. If you use policy verification then you need to use a hybrid approach of using remote selang commands (or maybe a post-install script if you're not planning to use the variable on systems that haven't been installed yet) before you deploy the policies to ensure they are executed. If the variable doesn't exist then the policy will not deploy because there's no value to expand the rule to yet. If the variable exists with multiple values (eg, one for each possible file location) then the policy will fail verification checks if you have enabled them and not deploy. If you disable policy verification and set multiple values (where one or more value is invalid) then the policy will expand the variable and generate a new rule for each variable value everywhere the variable is used.
EG, ACVAR with 2 values: "D:\jboss\" and "/opt/jboss/" used in a single FILE rule like 'nr FILE <!jboss-dir>*> defacc(all) audit(success, failure) owner(nobody)" will expand to TWO file rules and try to deploy them both. The first will fail on Linux because there's no such directory and second will fail on Windows. Policy verification will not deploy a policy if there is a failure. If you don't have policy verification then it will 'Deploy with failures', and might also (I haven't checked) generate a deviation status for the policy. However, if you don't mind sifting through the partial failures to ensure the only failures was due to the invalid value for that OS then you're okay.
This is where a more dynamic selang command language would come in useful. Some if/else statements and simple existence check as an operator for them in the selang command language would combine really well with the existing ACVAR without requiring a hybrid approach that requires manual selang commands directly on the endpoint or on legacy PMDB hierarchies to use non-builtin ACVAR at scale. For example, if this functionality were added then users could define ACVAR in a dynamic fashion, inside a policy, without completely failing when using policy verification or generating a 'deployed with failures' status when not. One would simply define an ACVAR creation policy that looks kind of like:
if-exists /path/to/file ("er ACVAR customVariable value(/path/to/value) owner(nobody)")
if-exists /path/to/other/possible/file/location ("er ACVAR customVariable value(/path/to/other/possible/file/location)")
Then your second policy which uses this variable can be created with a rule like "er FILE <!customVariable> defacc(none) audit(all) owner(nobody)". Since only one variable value exists, policy verification will not fail (so policy will actually deploy) and without policy verification the status of deployig the policy would be 'Deployed' rather than 'Deployed with failures'.
This would be particularly helpful in a scenario involving policy verification where the impact of a failure is more significant than a FILE rule not being implemented. For example, if you have custom SSH daemons installed on some systems and need to define them in LOGINAPPL to properly detect logins, which is required to properly associate identity to a user and interpret authorizations correctly (instead of interpreting every user as root or the operator of the third party daemon).
The only really 'easy' ACVAR to use are the built-in types and the osvar type in combination with default OS environment variables (so you wouldn't have to take manual action on any endpoint).
The current best approach for using static ACVAR without policy verification inciting 'failure' status or generating 'deployed with failure' status with no policy verification is to run the static ACVAR creation commands manually on the endpoint (hopefully as a post-install step so you don't need to run remote commands against 15k servers manually or with third party automation tools).