The best use case is to not fire an action if you know another condition exists, similar to your example over in .
When the Exchange service stops, it might trigger other errors that normally you'd send an email on. If this frequently happens, you could set a state variable when the service stops, and check it on the other events.
If an outage triggers an ongoing condition, set a state variable when the outage first happens, and if you have a rule on the ongoing condition, set it to check the state variable before alerting you.
Create more "sensitive" rules that are only triggered when another condition is met. For example, if someone gets a virus, maybe you monitor internal network scans or lower your threshold for logon failures, but normally you don't care. As long as that state variable is "DEFCON level 5" your rules just don't fire.
You can also add/remove to a user-defined group dynamically, which is a pretty basic concept but similar to a state variable. You could have a list of machines that were "known infected" (we've had people with serious outbreaks use this) that you remove from the list as you clean them up to avoid you getting inundated with notifications. Or the "DHCP but no Agent" rule example, where it creates a list of systems without an agent that maybe you need to monitor differently, or individually address, but don't want to receive continuous alerts about each time it happens.
We had intended/do intend to extend them based on need, to cover cases like timers (a decaying variable that expires and can trigger a rule on its own... sound familiar?) and lists of information. The need hasn't entirely existed, so far we've been able to work around most cases.
