Need help figuring out why my light turns off. If you look at the log, you can see it sets the light to 80% but then a few seconds later it turns off only to be turned back on when the restore function gets called.
Not sure if this would actually cause your problems, but from the second set of logs you posted, it appears that the rule actions are running twice in quick succession. Often, this would be the result of multiple trigger events matching around the same time, though the cause isn't clear to me from your logs (I don't see this happening unless there is more that was cut off--is it possible you are pressing the button around the exact time the sensor becomes present, or does one in fact also cause the other? or do either of these devices generate duplicate events? but mysteriously, this doesn't seem to start happening until midway through your actions).
Structurally, you are missing the final END-IF, which I'm mentioning only because someone will. 
But RM will infer it here, and it shouldn't actually cause this problem. The only other thing I can think to check is what other apps/automations might be using the problematic light. Check the "In use by" section on its device page and make sure nothing else (assuming there's more besides this rule) might be causing this behavior--whether on Hubitat or something via a third-party integration like Alexa if the device is also exposed there.
Re-creating the rule is also something you could try just in case something got "messed up" during the creation or editing of this one. Just a few ideas that might help! I don't see anything obviously wrong myself. Maybe someone else will see something...
This particular light only has one other rule which turns the light on at sunset and off at a random time after 10pm.
As far as the duplicate actions, its my Nest Doorbell so it is action on presence (person detected in camera) or button push. The duplicate events are a whole other issue I am trying to figure out the best way to deal with but to make sure that wasn't the cause of the problem I did try modifying the rule to only use one of the triggers with the same result.
I will try re-creating and see if I get a different result.
Keep in mind that it's also possible that either of these attributes (event names) could itself be generating a duplicate, so it doesn't have to be different triggers but could also be a single trigger firing twice in a row. Normally, the platform filters out "duplicate" events (report of new attribute values that are not different from the old ones--e.g., "present" if currently "present") unless the driver says not to, but if the driver is (likely erroneously) sending duplicates with a few hundred milliseconds or so, it's likely generating them faster than the platform is able to recognize the (lack of) change and filter them out. Checking the "Events" button/tab on the device page would be one way to see--if you see what appear to be duplicate events in a row (say, within a second or so), that is likely the problem.
There are probably ways you could work around this in the rule (not sure if that's what you're trying with Private Boolean, but I assume that's a different issue--just trying not to re-capture while you're still in the countdown). A local boolean variable you create to track whether the rule already started running the action is one way, assuming RM commits the value faster than the next trigger fires to read it. But a fix at the driver level would be the ideal solution. Based on the device names, I might assume these are community drivers, so that would fall on the author or another knowledgeable coder.
But that could be going down a path/possible explanation that isn't really relevant here. Just if it is... 
Well my own arrogance was my problem. I was so sure that there were only 2 rules impacting that light I missed the fact that I had created a test rule a few weeks earlier that was the culprit. Once I deleted that rule all works as designed.
Slightly revised the rule. I got rid of capturing the state and instead rely on the other rules that control this light to update the private boolean to indicate if the light is currently supposed to be on or off so I know what state to return it to.
