I would not combine them in this case. You should separate out the rules that are able to change the virtual switch from the rule that define what happens when the switch is switched. This will keep your logic much easier to follow later on when you start adding all sorts of conditions and stuff to your rules to make them do what you want later on. Since the LED is supposed to indicate the state of the virtual switch, it would be included in the "Do this if switch is ON" rule.
I may have several different rules or ways to enable a switch or mode, but I always have just a single rule that includes ALL the actions that will happen when that switch state changes. I have my "trigger" rules, and then my "actions" rule, if that makes any sense.
I would not combine them in this case. You should separate out the rules that are able to change the virtual switch from the rule that define what happens when the switch is switched.
Yes, I generally agree with this. But I don't view the indicator as "what happens when the switch is switched." I view it only as a visual indicator. I get that one of the things that happens is the indicator. For much of the time the only thing that happens is that the indicator is on.
Since the LED is supposed to indicate the state of the virtual switch, it would be included in the "Do this if switch is ON" rule.
This part won't work for me. When an overnight guest arrives, I hope to remember to turn the Guest switch on. But nothing in particular will immediately happen. The "Do this if switch is ON" rules are essentially conditions on other normal rules. As an example, I have an automation that includes turning off lights in the Guest Hall at night in case they were left on. I will will add a condition to this automation to only run the Guest Hall lights out portion of the rule if Guest Switch is off.
but I always have just a single rule that includes ALL the actions that will happen when that switch state changes.
But nothing really happens. It's just that later, a subset of things that usually happen don't happen.
Hubitat gets a low HAF if it turns off lights on the guests when they don't expect it, so right now I just suspend the entirety of some regular rules and do things manually. I want the guest switch so I can let the rules run and they don't turn off lights on the guests.
This makes perfect sense to me. I do exactly this method ALL the time in my rules.
There are so many different ways to do things within Hubitat that I encourage you to explore a bit. Some of my rules have actions tables that are literal pages long if you put them onto paper. The rabbit hole goes very deep.
AHH! Now, I see why it doesn't work the way the original rule was written: it is written such that is it looking for the button number that is being pushed or held. In this particular case, "3.0" is the output whether the button is "held" or "pushed", so the rule will always execute only the on command, since both produce the same output.
Let me think for a sec, I'm sure there's a way to do it where the button mapping doesn't screw it up.
EDIT
Since you have to use the custom attribute action to check the "pushed" and "held" attributes, and in both on/off commands the result would =3, I have to find another way to differentiate between the two states so that you can use a single rule to combine both on and off functions. For now, it seems separate on and off rules will be required. There may yet be a way to do it in one rule, but I'm drawing blanks at the moment
Rule Machine doesn’t really do button toggle very well, which is the issue you are running into. If you use Button Controller or even Room Lighting, you could have a single instance to flip the virtual switch.
Bit late in my response (by my standards... )... I would say I am not as organised as I may come across. I may speak of lofty intentions, and I may adopt some of the approaches I outline, but when it comes to broader organisation or pre-planning like others have described... That's not so much what I have adopted. In theory I get and can appreciate how people may go for a more organised and well-documented approach, but I tend to adopt a more "agile" approach, which I would also label as a "lazy" approach I try one way of constructing my rules, if that doesn't work I post about it here and adjust based on feedback, repeating this cycle as long as needed.
)... I would say I am not as organised as I may come across. I may speak of lofty intentions, and I may adopt some of the approaches I outline, but when it comes to broader organisation or pre-planning like others have described... That's not so much what I have adopted. In theory I get and can appreciate how people may go for a more organised and well-documented approach, but I tend to adopt a more "agile" approach, which I would also label as a "lazy" approach 
I try one way of constructing my rules, if that doesn't work I post about it here and adjust based on feedback, repeating this cycle as long as needed.
