In the grand-parent comment's example, you just want it to be more readable, because it is a once off block of code, so that whoever maintains it next can easily figure out what it is doing. Moving it into a function doesn't stop it from being a once off block of code, and we need to be careful not to increase complexity for the sake of it. By your last paragraph you had already introduced a configuration store and the concept of environments!
In all fairness, I led him that way. I called it "extracting configuration from code", which is reminiscent of #3 of the 12-Factor App (https://12factor.net/config).
You can extract config to various degrees. My example is perhaps the mildest: just group it together, near the beginning. You don't need complex frameworks. In fact this technique first caught my attention when I was reading other people's shell scripts.
The next step would be to move the config to its own file. This is very common in Linux. You have some tight binary, that is compiled and hard to change. But then you have config files, often with dozens of options. It's a nice way to do things.
The next step would be to move the config to a different level, no longer in a simple file. This is often either a relational database or environmental variables. Linux commands use environmental variables along with their config files.
For very large systems, this technique is the same in kind, just different in degree. You get fancy specialized systems, like Hashicorp Vault, to store your configuration, at least your secret ones, like passwords and stuff.
