Pulsing repeatedly to command devices on that should be on, while potentially effective, is like polling. When you poll for data, you get an answer, but the answer could be as stale as a fraction of a second less than the length of your polling interval. Poll every 60 seconds? A light can easily be in a different state for 59 second before you find out about it. Pulsing is similar: someone turns off the light, but it stays off until the next pulse comes around to command it back on. It works, but it’s the “lazy” way to do it.
A better approach is to combine your time conditions with goal states. For example, let’s say you want to ensure that a light stays on between sunset and 11pm. The straight-line solution is to make a condition group that addresses the time range, and turns on the light when it becomes true, but as you note, if the light gets turned off manually during that time, it stays off. Adding goal states entails checking the state of the device in addition to the time range: “if it’s between sunset and 11pm and the light is off”. In this scenario, any time the light is not on during the time range, the condition is true, causing the light to turn on.
The catch, though, is that now the condition goes false immediately after turning on the light (because the light is no longer off). That means you need to add a separate condition to make sure the light is turned off at the right time. You can’t use the “is FALSE” activity of your prior “turn on” condition group to turn the light off. In fact, if you try to do that, you will turn the light off… and on… and off… a lot… as fast as Vera and ZWave can do it (unless you’ve disabled the throttling in the ReactorSensor, it will stop eventually).
If you go this route, I also recommend adding a “sustained for” delay of a few seconds, to avoid any “short cycling” behavior of the switch that could damage either the switch or the bulb/fixture. What I mean by this is, without any such delay, as soon as you reach for the switch to turn it off, the Vera will turn it immediately back on. For certain inductive loads (like CFLs or LEDs), this can cause some heartburn eventually and shorten the life of the switch, device, or both. If you leave a delay of 10 or so seconds before the automation corrects your inappropriate behavior, it’s likely that everything has settled enough.
Finally, don’t read too much into my use of the word “lazy” in the first paragraph. The pulse approach is perfectly acceptable if that’s what your sensibilities allow. It is probably the simplest solution to the problem, just not entirely elegant or consequence free. Everything is a trade-off though, and the complexity of additional conditions should always be weighed.