It doesn't do that. The one in the post composes a bunch of other Behaviors, see the lowPower one further down in the article for an example, it's not polling a bunch of variables. Then it is all wired up to react to events.
To elaborate, lowpower etc. on this line are Behaviors, which emit values by time:
react <$> lowpower <*> fridgepowerchange <*> wifiusers
react lowpower fridgepowerchange wifiusers
| lowpower = Just PowerOff
| wifiusers > 0 = Just PowerOn
| otherwise = fridgepowerchange
Although this might have confused GP, I think this is nice since we can associate the name 'lowpower' for its semantics (The low power signal) and not have to worry about "this lowpower is a Behavior while that lowpower is a Bool".
But the value of writing this kind of code in Haskell is that Haskell makes code that couples very abstract interfaces VERY easily. This is really hard to explain without some examples, so I'm going to give you an example.
Here, let me show you from real code. I'm going to tweak some endpoint names, but this is real code I'm going to ship next week: https://gist.github.com/KirinDave/9b4380376f9f748bcf0f8440de...
What's cool about this code is that I'm describing a "generic" radAPI service with a bunch of endpoints stripped out. Everything is parameterized around 3 generic ideas: "p", the Storage service. "Patchable", a strategy for applying patches to a storage service (exposing runPatch), and "CanValidate", a strategy for authenticating requests based on some sort of stored string, auth headers, and body contents.
This is even better than mocking, because instead of deeply coupling the structure of my code to my tests, I only couple the capabilities.