The decision as to whether to expose an interface for non-technical personnel to modify business rules largely depends on several factors, including the goals of the project, cost of the project, lifetime of the project, and the ratio of knowns to unknowns in the project.
For instance, if I believed that no one would use the rules interface, then I would probably opt out of implementing it. However, if I had reason to believe that changes would be frequent and that different end-users would expect different rules to be in place, then I would consider working on building such functionality.
I chose to do this on a project, and it took years before the feature was ever widely used. I suspected that we would eventually have end-users who would want to customize things themselves, so we implemented this functionality in pieces.
It started out as something that only certain people, like developers or admins could use. The interface was clunky, but usable if you knew what you were doing. But by the time the product was nearing completion, the rules engine backend logic came in handy, and our design team gave it a beautiful, customer-facing user interface.
If I were to do it different, I might choose a different database architecture just because the learning curve is high. But in short, building it early on led to many customer facing features later on without the headaches of having to go back in the code and refactor it to include all of the dynamic rules.