Hopefully the preceding sections have explained when you may want to use a rule engine.

Alternatives are script-based engines that provide a mechanism for "changes on the fly" (there are many solutions here).

Alternatively Process Engines (also capable of workflow) such as jBPM allow you to graphically (or programmatically) describe steps in a process - those steps can also involve decision point which are in themselves a simple rule. Process engines and rules often can work nicely together, so it is not an either-or proposition.

One key point to note with rule engines, is that some rule-engines are really scripting engines. The downside of scripting engines is that you are tightly coupling your application to the scripts (if they are rules, you are effectively calling rules directly) and this may cause more difficulty in future maintenance, as they tend to grow in complexity over time. The upside of scripting engines is they can be easier to implement at first and you can get quick results. They are also conceptually simpler for imperative programmers.

Many people have also implemented data-driven systems successfully in the past, often using control tables that store meta-data that determine your applications behavior. These can work well when the control remains very limited. However their complexity can can quickly grow out of control as the applications behaviour is extended or they cause the application to stagnate as they are too inflexible.