If the requirements can change in future, is it a good idea to pull the business rules out of the code into a custom rule engine?

We have a requirement such that Users need to be presented different facts based on some constraints.

Similar Hypothetical Example

If User belongs to Australia and earns more than 10k$ then show XYZ view of data/facts
If User belongs to USA and earns less than 5k$ then show ABC view of data/facts
...
...

Now we can either,
keep this mapping in the user model and have these business rules in the code
or
we can pull these rules out into a JSON or a DSL where we can simply change the rule without having to deploy the code for every single change.

We dont know how frequently these rules will change.

I have read arguments for and against the idea of a custom mini rule engine.

Arguments for:

1. Every small change will not require a deployment
2. All the rules related to this specific functionality are at one place (probably) making it easier to get an overview

Arguments against:

1. (Martin Fowler article) It will become difficult to reason about your code
2. Anemic Data model anti-pattern
3. Over time it will be difficult to manage these rules
4. Conflicts between rules or the chance of some facts not belonging to any of the rules