When I first wrote Rule Machine I didn't think I needed it, as my approach was to write a small Groovy app for each automation I needed. When I discovered that I was using one app more than once, I'd poke at it a bit to get what I needed for multiple uses. This is how Motion Lighting came into being.
Since then a few things happened. Rule Machine grew from about 2700 lines of code to over 7000 lines of code. Motion Lighting grew a lot also, adding options for every variation people came up with. There's a real tradeoff here: RM can do pretty much anything, but it's big and bulky. Personally I only use a small fraction of it. A streamlined Motion Lighting still makes sense.
When I was a computer science grad student (decades ago!) I worked on language translation, software portability and abstract machines. I don't have the time now to do the sort of projects I did then. But what would make the most sense to me would be to create a "compiler" that would translate an automation definition into a simple Groovy app. For example, the "piston" definition for webCoRE, or the inferred "language" of a Rule as summarized on the Rule main page could be translated into a Groovy app. I can easily do this by hand, taking just a few minutes to do it. To create a compiler to do this would be a challenging project, but doable. The first step would be to define the automation language. Then, from that, write the compiler that generates Groovy. It wouldn't really matter how efficient the compiler would be, because the generated Groovy app would be tiny and super efficient when it runs.
I heartily endorse the idea of writing your own small apps to do automations if you have the skill to do so. This approach yields the fastest possible automations, each perfectly optimized to its use case with no extra complexity.
Hmmm.... maybe it's time to go back to grad school. 
