... however this is more challenging because it is necessary to recompile and deploy. Therefore I am wandering if the business logic should be contained in the database ...
You've got a point, but it only covers part of the logic.
Yes, age is just a number, and thus data. If the age changes from 18 to 21, that can be handled with a simple config change. But how sure are you that age is just a single number?
For example, if the minimum age changes for some of the users (e.g. based on their nationality or gender), that's not as easy anymore. You'd then need to have config settings for every combination of nationality/gender, which can lead to a whole lot of bloating in your config files. Whenever a nationality gets added (which would likely happen at runtime without needing a redeploy), you'd need to add the new nationality's config settings as well.
The thing is that changes to validation rules are not always as simple as changing a value. When some of the behavior changes, you're always going to be stuck having to redeploy your application. Even if you ensure all values are easily configurable, that only covers a subset of possible changes that can be made to the business logic.
The question then becomes whether the benefit of being able to swap the values (but not the logic) meaningfully contributes to the application. If any change to the validation rules should be treated as a change with major impact, there's little reason to ensure values changes are notably easier than logic changes.
Secondly, having the settings in the compilation means that you have some form of consistency guarantee. If you compile the minimum age into the DLL, then you know that the same version of the application will never alter its behavior. Especially for high importance systems like banking, that added layer of behavioral immutability can be desirable.
Regardless of business validations, you will always have a secure production environment because you want to prevent people from wantonly swapping the DLLs (whether it's malicious intent or reckless maintenance). If you have that security in place anyway, having the validation rules compiled into your DLL inherently means you have the same secure environment to guarantee that no one changes the validation rules (whether it's malicious intent or human error).
In the end, whether you put your validation rules in the database, config file, or assembly hinges on one question: Do you want to be able to change validation rules without redeploying the application?
There is no objectively superior answer to that question. Different companies have different priorities, and different types of validation can have different impacts on the business when something goes wrong.