You overlooked to mention in your first post that there was a fan involved. Nevertheless, neither of the two cases you described prevent the use of a Numeric State Trigger provided it is accompanied by an appropriate State Trigger and matching conditions. That’s exactly the design pattern that Septillion’s examples use.
It’s a common pattern and far preferable to another anti-pattern (i.e. not recommended way of doing something) that employs a Time Pattern Trigger to repeatedly poll an entity’s state.
I think the problem with that is that if the fan is on and the humidity is above 53% but someone turns off the fan it’s now off but hasn’t been off for 10 minutes so the action won’t trigger and will never trigger again until the humidity crosses the 53% threshold again.
Humidity 60 —> Fan Switched Off —> Automation is triggered —> Both conditions satisfy —> Fan should be on?
If you need to wait 10 minutes after switched off manually, you can use trigger ID as the trigger condition - then add 10 minutes delay before switching on the fan.
I think it is okay for you to remove the input_select?
Edit: Didnt notice that the 10 minutes delay after switched off manually involves WAF
No you didn’t, because you turned it off What you really wanted was a 10 min break. Aka, after 10 minutes off (trigger) check if the humidity is still to high (condition), if so, start again.
Is the sensor indeed just 1% accurate? But besides that, without a state it will trigger on every change of the entity, not only if the actual state changes but also on attributes.
No, because there is a difference in only triggering when the threshold is crossed and triggering when you want to When you want to simply adds the trigger of “10 minutes off” to the list So simply add that trigger to the list!
My wife turns it off because she doesn’t want to hear it even when I ask her to leave it on So the compromise was for it to be off for 10 minutes…another reason why I need it to turn on again even if the humidity doesn’t drop below 53% and then exceed it again.
Anyways, I believe at this point we are debating more about my logic rather than the actual behavior/logic of how the HASS automation engine works.
I believe what I’ve coded gives me the behaviour that I’m after regardless of the human factors in play
But my point was, take that into consideration when you pick the triggers
Back to the analogy of cooking, don’t trow out the timer and watch the clock every second when you want a hard boiled egg and your wife would like a soft boiled egg. Simply set a timer when your egg is don but also set a timer for when your wife’s egg is done and simply look what needs to be done when a timer goes off.
Aka, indeed not only trigger when it goes above the threshold but also when you actually want the fan to resume when it was turned off instead of constantly checking it.
So yeah, it’s about your logic. But more importantly about how to make good automations. Because he, you could just switch to polling every second for all automation but that would not make great automations. High resources and very hard to debug, even with the debug tracer.
What you really wanted was a 10 min break. Aka, after 10 minutes off (trigger) check if the humidity is still to high (condition), if so, start again.
So simply add that trigger to the list! 
So the compromise was for it to be off for 10 minutes…another reason why I need it to turn on again even if the humidity doesn’t drop below 53% and then exceed it again.