True. (But in case it amuses you or others reading along:) But a code settings file still carries it's own special risk, as an executable file, in a predictable place, that gets run regularly.

An executable settings file is particularly nice for the attacker, as it's a great place to ensure that any injected code gets executed without much effort.

In particular, if an attacker can force a reboot, they know the settings file will get read reasonably early during the start-up process.

So a settings file that's written in code can be useful for an attacker who can write to the disk (like through a poorly secured upload prompt), but doesn't have full shell access yet.

They will typically upload a reverse shell, and use a line added to settings to ensure the reverse shell gets executed and starts listening for connections.

Edit (because it may also amuse anyone reading along): The same attack can be accomplished with a JSON or YAML settings file, but it relies on the JSON or YAML interpreter having a known critical security flaw. Thankfully most of them don't usually have one, most of the time, if they're kept up to date.