It is more efficient to have them all in one trigger for a number of reasons. Whenever an app runs from some event, the app and all devices associated with it must be loaded from the database, and the test for restrictions that might apply has to run. So by splitting it up, you incur this overhead on each action. The overhead is certainly measurable in time.
So best practice would be to fire all of the actions from one trigger event.
On this same topic (sorry to add to your question but something I have wondered about too) is whether it is better to use Restrictions or conditions. Restrictions allow for checks of modes and times, yet I can also includes modes and times within a rule condition. Is one more efficient than another? From my viewing logs, it appears that restrictions are evaluated first and the condition never gets evaluated so based on this finding I would say restrictions are better but I would welcome @bravenel's input.
They are actually different, so the answer depends on what you are trying to do. The main difference is that since restrictions are not conditions, they do not cause rule evaluation to occur when their state changes.
For example, if you restrict a rule to only run between 1 pm and 5 pm, nothing happens to that rule at 1 pm or at 5 pm. Whatever does cause that rule to run will cause the rule to first check to see if it's between 1 and 5. On the other hand, if 1 pm to 5 pm is a condition, then the rule will be evaluated at 1 pm and again at 5 pm. Say you want lights to come on at 1 and off at 5, you'd need the time window as a condition. If you want the lights to turn on when someone opens a door, but only if it's between 1 and 5, you'd use a restriction.
As I stated above in my prior post, the overhead of loading an app and its devices from the database will happen whenever something causes the rule to be run. Once that overhead is incurred, the restrictions are checked automatically. We actually had a discussion recently about whether it would make sense to set a state variable that says there are no restrictions, to make the restriction check slightly more efficient in the case there are none (the usual case). But, the difference in compute time is minimal. It doesn't take long for the processor to run through the code checking restrictions and evaluating a rule.
So I'd say whether or not to use a restriction boils down to the logic you are trying to accomplish, not efficiency.
Thank you very much for the detailed explanation. I work for a software company and with most software there are many different ways to accomplish the same thing, but obviously some are more efficient than others and that is where this question stems from.
I'm trying to streamline my rules to A make thing clear and easier to read/ change, B make the different apps IE RM and motion lighting work better together and C hopefully take less resources from the hub. From what @bravenel says it may not make a difference in my case but before I had something like this
trigger
modes and if switch came on condition
only when the switch is on if true
set the dimmer level/ temperature level per mode if false
nothing
I would have one of these per light so if the mode changed and the light was ON the lighting output would change or if i turned them on they would match correctly to the level. The problem i suspected was that this rule was running in the logs on each mode change, so in my mind not ideal?
Today I tested and changed it to a trigger (rather than trigger rule) and set the restriction to be only when the light switch was ON (no logs when mode changes now unless the light is on) I was worried it wouldnt evaluate when you turned the light on but the hub is so fast it unrestricted it and uses it as a trigger all at once, great! So 1st question is this a efficient good/ correct way of doing things?
next point, I have motion sensors and switches and I was using motion lighting to change the light level/ colour depending on mode with mixed results (SM Lamps, Dimmers and RGBW controllers inconsistencies in all of them) during this time i had the original rules paused. So now going back to the triggers and just getting the motion lighting app to turn ON the lights and letting the trigger to do the rest (still to test). The problem I have is two fold 1. RM currently does not support colour per mode (hopefully soon ) and 2. I will also have a switch trigger rule that will turn on or off the light if the switch position is changed. Now in the day it's fine because I use colour temperature and this would be in my trigger mode On set up, but at night from the motion app i have the SM Lamps come on RED and at 1% so not to fully rouse the baby as we carry her around. What I want to be able to do though is if i use the switch at night I want it to come on a temperature value for a emergency for example. So i'm essentially using the ON state of the lamp/ dimmer as a variable which is not what I need in this case. So with my "more efficient rules" is there a way in RM to essentially ignore my normal rule and use another at night when a contact or button is used?
Edit: I essentially need a virtual switch then a option for another restriction of that switch which would need to toggle if i use the light switch in mode night-sleep and only in night sleep have the values i want it to go to in the switch rule. The problem with that is there is no way to order in RM so I can't say if in this mode do this V switch before turning on the light it also won't let you have more than one switch as a restriction, meaning more V switches and rules. I miss WC
Not sure why you'd think this is a problem. You've got a quad-core 1.55GHz processor. How many times a day does the mode change? Logging is nbd. This is not a problem!
I think you are over thinking this, and making it more complex than it needs to be. Try to lay this need out in simpler statements, maybe even show it as a piston.
good to know, it doesn't change often it was more of a case that this rule is repeated 15+ times so, in my 1st set up they would all run (seem to even though lights were not on), where as on the 2nd set up they (look like) only run if the light is on.
100% im sure I am, hence why I put it on here i'm hoping for someone to call me out as a numpty and make me see the wood through the trees I will see if i can work out a clearer "flow" to explain it.
) and 2. I will also have a switch trigger rule that will turn on or off the light if the switch position is changed. Now in the day it's fine because I use colour temperature and this would be in my trigger mode On set up, but at night from the motion app i have the SM Lamps come on RED and at 1% so not to fully rouse the baby as we carry her around. What I want to be able to do though is if i use the switch at night I want it to come on a temperature value for a emergency for example. So i'm essentially using the ON state of the lamp/ dimmer as a variable which is not what I need in this case. So with my "more efficient rules" is there a way in RM to essentially ignore my normal rule and use another at night when a contact or button is used?
I essentially need a virtual switch then a option for another restriction of that switch which would need to toggle if i use the light switch in mode night-sleep and only in night sleep have the values i want it to go to in the switch rule. The problem with that is there is no way to order in RM so I can't say if in this mode do this V switch before turning on the light 
it also won't let you have more than one switch as a restriction, meaning more V switches and rules. I miss WC 
I will see if i can work out a clearer "flow" to explain it.
