^^^This.
Every HA flavor I have tasted in the last 2 decades has had “scenes, action groups, macros” or whatever you want to call them. They were essentially a list of device settings/commands that were saved, and callable from any other part of the program.
They also implemented triggers the same way; all saved. Time based, motion based, etc. This allowed a simple way for any rule to disable it for a given amount of time, or given device state. I know SmartThings tries to accomplish this with modes, but it is far too all-encompassing, having to think about more modes and all the SmartApps that need to be filtered by them, when I should be able to simply command “disable this trigger for the next 15 minutes” or "disable triggers 5,6,7,9, while var/mode/whatever “away” is true. Instead, we now have to disable the entire smart app for that mode, which means we may need to create another, near identical one to continue to do the other things we want to have happen while we’re “away”.
While it is certainly possible to create a rule builder that writes and instantiates a SmartApp in its current state, it would be far more complicated than if we were to have these triggers, and action groups persistent, and available globally. Then it is simply a matter of:
1.) Define trigger (device event or state)
2.) Define conditions (multiple: with AND & OR)
3.) Define action (or select a previously created action group) to perform.
Yes, all of the above could most likely be written with a smart app today, but it forces the creator to foresee every possible device, capability, and conditional, which takes a lot of work and ends up being a complete mess (interface wise), so what we end up with, and have now, are a ton of one trick ponies that are a bit of a mess to manage. And then of course, if new devices are added (with new capabilities), that app would need to be revisited.
SmartThings already knows about all of our devices and their capabilities, even when we add new ones, and EVEN when we mod the device-types to do more with them. So, it should be possible to simply provide us with a hierarchical list of choices that are apropos to each of the above definitions at any given moment… ala:
1.) Trigger>deviceListORtimeDateEventPicker>availableDeviceEvents/States
2.) Condtions>deviceListORtimeDateEventPicker>availableDeviceEvents/States (multiple: AND & OR)
3.) Action>predefinedOrNew>deviceList>setableStates/Properties (multiple)
Just my 2¢