It may be helpful to first explain what you want the rule to do. I have an idea from what you wrote, of course, but I suspect that what you wrote isn't exactly what you want (more on that later). Because it appears you basically want to do three different things in response to three different triggers, I would write three separate rules.
The total number of apps/rules should have minimal impact, especially if they all have different triggers (it's probably best to make each app subscribe to the minimum number of events it really needs and for each device event to be in use by the minimum number of apps, but in regular usage I still can't see this making too big of a difference either way). With Rule Machine, Bruce's recommendation is generally that smaller rules (multiple rules if necessary) are better than one large rule. As a benefit to you, they are also generally easier to edit and "debug."
In your case, perhaps you want something like:
Rule 1
Trigger: When time is sunset-20 minutes
Actions to run:
IF (Lr Curtains Auto/Manual is on) THEN
On: Lr window Shade Switch
open() on Lr Window Shade Control
END-IF
Rule 2
Trigger: When time is 1:30 PM
Actions to run:
IF (Lr Curtains Auto/Manual is on) THEN
Off: Lr window Shade Switch
close() on Lr Window Shade Control
END-IF
Rule 3
Trigger: Lr Window Shade Switch turns *changed*
Actions to run:
IF (Lr Window Shade Switch is on) THEN
close() on Lr Window Shade Control
ELSE
open() on Lr Window Shade Control
END-IF
If you're super-concerned about efficiency, you may consider re-writing that third rule as:
Trigger: Lr Window Shade Switch turns on
Actions to run:
close() on Lr Window Shade Control
Wait for event: Lr Window Shade Switch turns off
open() on Lr Window Shade control
(This is another difference that's unlikely to matter in real-world usage, but it's theoretically more efficient: in the original rule, you're triggering on change, then checking the current state. In the latter, you trigger on the specific event that causes that state, so you don't need to check--the trigger is enough. The "Wait" creates a subscription to the other event (switch = off) only when needed. It's also probably easier to write.)
Back to these three rules as a whole: together, they may look similar to what you wrote above, and I suspect it's what you want, but it's not exactly identical. First, with the original/big rule, if the "Lr Window Shade Switch" switch state changes and it happens to be 1:30 PM or sunset-20, that first set of actions will execute, not just your last IF. (I'm assuming you only want the last IF block to execute, though I suppose this is unlikely to matter in real life since it's likely the time-based blocks would have just run and already be in the desired states.) Similarly, when the time is 1:30 PM or sunset-20, one of the IFs inside your first IF will execute, but so will your last IF, the IF (Lr Window Shade Switch is off) THEN (or its ELSE).
Splitting the rule out into three like this solves all of these problems (and avoids you needing to so much work in the actions to figure out why the rule triggered). Each rule is also small and clear in purpose. I do understand that you may prefer everything to be under one "roof" to keep things more organized, but as you know, the UI does not provide any way to group rules manually. Since app names are sorted alphabetically by default, I would consider naming your rules in some sort of pattern as a workaround for this.
You could, of course, also write a custom app for this. From what you've written in other threads, I really think you would be happier that way in the long term. If you have an idea of what you want the app to do--maybe something like this rule?--I'm sure someone here (I'm kind of volunteering myself, but I'm sure there are others) could help you get started. But I don't think what you're doing is stretching the limits of Rule Machine at all (I've seen far worse 
) and wouldn't say that learning how to write an app is necessarily something you need to do just for this.
