Rule-engines have a special advantage over their imperative counterpart. Lets get some footing with a quote from Martin Fowler:
A rules engine is all about providing an alternative computational model. Instead of the usual imperative model, commands in sequence with conditionals and loops, it provides a list of production rules. Each rule has a condition and an action – simplistically you can think of it as a bunch of if-then statements.
Now, each rule you add to the system is there to stay, assuming you don’t delete it. Meaning, it will never be bypassed. An imperative model is sequential. It’s easy to bypass a whole block of functionality but that creates an unintended path of execution. It’s a monolithic approach and unless you fully understand the whole system it’s very easy to cause bugs.
A rules-based workflow approach is less prone to these types of bugs, at the cost of lower visibility of the execution path though.
Additionally, to make a change to the system, any engineer can add a rule without having to fully understand the rest of the system. If the new rule makes logical sense to the company, it will fit into the pre-existing rules. An example of a new rule: “If a new customer is added, add a reminder for a welcome call”. In that situation, the most likely bug might be a double notification if someone else added the same rule. Even that is easily avoided with a check to verify a notification hasn’t been sent.
In the long run rule based systems are able to avoid some of the traps that usually accompany large legacy code bases. I suspect the laws of diminishing return with legacy code will be much less of an issue with tools like NebriOS. Prove me wrong!