You can use CommandStats to simulate an OR gate while reducing the amount of required command blocks (since you'd essentially be running two commands for the price of one).
Prerequisites
Objective to hold the CommandStats result.
/scoreboard objectives add Condition dummy
Single armor stand to summon, which could also be used for other chains that needs it (as its score is to be reset at the beginning of the chains). This will be the entity subject to CommandStats.
/summon ArmorStand ~ ~ ~ {Tags:["conditional"]}
Mechanism
Example mechanism (you can swap out the impulse for a repeating block):
Command blocks 2 and 3 will be the initial conditional blocks, where if either are successful you would run more commands. Place a temporary command block above each of them, place the following command inside it, and activate it (you would otherwise just run the command yourself, but the character limit was exceeded):
/stats block ~ ~-1 ~ set SuccessCount @e[type=ArmorStand,tag=conditional,score_Condition=0] Condition
Now if either of those two commands run, the armor stand will have their "Condition" score set equal to the number of successful iterations of the command.
However, it will only target the armor stand if it has a "Condition" score of 0. This means that if either of them are successful, the score will be 1 and will remain at 1 even if the next command block is unsuccessful.
Commands
The following are the commands for the example mechanism above.
Set the armor stand's "Condition" score to 0. This is needed so it can be targeted by this chain again.
/scoreboard players set @e[type=ArmorStand,tag=conditional] Condition 0
One of the conditionals to check. The success of this command will trigger its stored CommandStats.
/scoreboard players test #DAYTIME daytime 0 1000
The second conditional to check.
/scoreboard players test #DAYTIME daytime 12000 13000
After the conditionals have finished, the armor stand will have a score of 1 if either of them were successful. You can then detect this armor stand with a score of 1.
/testfor @e[type=ArmorStand,tag=conditional,score_Condition_min=1,c=1]
Command(s) to run if either of the conditionals were successful.
/say The time is either 0-1000 or 12000-13000.
It's server lag; the server is given a huge amount of work and it will take longer to finish the job, which causes most things to grind to a halt until it's finished.
The command parser will separately execute a command for each individual target obtained by a selector.
For example, when running the following while there are 1024 armor stands:
/execute @e[type=ArmorStand] ~ ~ ~ /testfor @e[type=ArmorStand]
There are 1024 /execute commands being processed, and then for each and every /execute command processed there are 1024 /testfor commands processed (totaling 1,048,576 commands processed). This is an extremely large amount of work that needs to be done, and it's only a single /execute.
The more nested executes you use, the worse off it's going to be. Not only do the commands have to be processed thousands of times, the selectors do as well (which comes with some heavy operations, such as sorting all targets by distance before picking from them).
Best Answer
On the tick that a command block is powered, it is queued for the next tick to run its command and then moves along the chain blocks and also queues them for the next tick. If a chain block found during the trail of activation is already queued, then it doesn't need to queue again.
As such, if all 3 of those command blocks are powered during the same tick, then every chain block will run only a single time.
However, the order of the queue is dependent on the order the impulse blocks activated.
If command block a is activated first, then the order of operation for the chain blocks will always be 1, 2, 3, 4. If any of the other impulse blocks activate after, the chain blocks were already queued so cannot be queued again.
If command block b is activated first and followed by c and then a, the order of operation for the chain blocks is 2, 3, 4, 1. Impulse block c is essentially does nothing to the chain since the chain blocks it would queue have already been queued.
And if command block c is activated first, followed by b and then a, the order of operation is 3, 4, 2, 1.
But since you have those chain blocks blank, then that will not matter, and chain blocks 3 and 4+ will always activate only once as desired.