Here are my two cents.
Config files
I agree with what was said before: with the current implementation they are a development hurdle. It is very inconvenient to add new config file settings to the game; they are kind of a workflow killer. However, config files do form an interesting middle ground: They allow server operators to adjust the game without being able to compile it, yet users are at least minimally warned that the server they play on is modified (although users have no reasonable way to know how).
I find that the first advantage of config files, allowing modifications without compilation, is only a minor advantage. We are talking here about servers that do not add any interesting gameplay elements (no new weapons, classes, structures) nor propose an interesting redesign of something that exists. Any such nontrivial modification would immediately require code changes (which are easier if config files don't exist). killing time summed up what I also think:
killing time wrote:"Mods" created by merely changing the config files are something I would frankly rather discourage
On the other hand, the second advantage of config files, that they communicate at least that a server is modded, I find rather important. If servers could be modified without players being aware of this, this would be a large problem for anyone except for the server operator: both players and developers suffer from this, as detailed below. Config files at least require that a mod-*.dpk is downloaded by each player, giving a minimal warning that changes were made.
Developers would suffer from hidden mods
This is because they would not receive correct feedback about the state of the game. If a problem in the vanilla game is resolved by invisible modifications on the populated servers, then developers are less likely to become aware of this issue, leading to a stale vanilla game. A hidden change of one aspect of the game could even prompt users to ask for a change of some other aspect, leading to the vanilla state deteriorating. Only if players and developers are aware that, and also how, a server is modified, the base game can improve as a result of good changes.
Players would suffer from hidden mods
This does not apply to all modifications equally. It applies very heavily, in particular, to modifications to combat balance. There are at least three important combat skills: aim, movement, and situational awareness. Aim is what most players already bring, movement and awareness are what separates experienced players. With awareness I refer to the fact that experienced players will know instinctively when they have to switch between aggression and fleeing. They are thus more likely than newcomers to win a fight or retreat from a fight with very low health. This is in essence a consequence of health pools, damage values and attack frequencies being turned into "muscle memory". Improving at the game is fun and involves building up this kind of muscle memory.
The mentioned values can be changed by config files and every such change will make people adapt in the long run (regardless of whether players know if they play on a modded server or not, though knowing about changes gives them more agency). At the end of the day, players profit if combat balance values are equal on all servers they play: they can improve gradually, enjoy multiple servers, and do not suffer from badly informed decision making. So even though one could think that modability is the highest goal, here central decision making is in the best interest of the player.
The role of cvars
Cvars have some immediate advantages over config files: They are much easier to set up, you can more easily tune them when looking for a good default value, and one can later configure them on a per-map basis.
But, at this point cvars are only sent to the client if they are needed for predictions to stay in sync with the server, and even in these cases, non-default values are not clearly communicated to the player. So it is safe to say that cvars are hidden modifications. Unlike config files, they even open the door to abuse as server operators could change them mid-game without anyone noticing.
Why are some gameplay elements still configurable via cvars? This is only because for some aspects, which are not related to combat, we do want variance in the server landscape, and likely the developer couldn't be bothered to realize it via config files. For instance, it's nice to have servers with small maps and quick unlock progress alongside servers with large maps and, say, a high number of build points to allow for longer games. This tailors to different types of players and their needs, without causing bad muscle memory: these changes are either clearly communicated during the match (e.g. number of build points available) or they do not matter so much for a player's decision making (e.g. you want to gain momentum quickly regardless of how much you need for the next stage).
At this point in time, I'm not aware of a single combat related configuration that can be set via cvars, and for now I would prefer that it stays like this.
Looking forward
I think one could make pretty much anyone in this thread happy if there was a setup (possibly extending current cvars) that
- was as easy to develop with as static cvars,
- is possibly more structured than them (as freem pointed out), and
- enforces a clear communication of any modification to the player.
For (3), I wouldn't accept anything lesser than a popup or similar UI element shown on connect and map load. For any non-default, gameplay-relevant setting, it should list the current value alongside the setting's default. Changes to these settings during the live match should either require /devmap or show a warning to all clients. Players need this level of insight.
Until we have such a system, hardcoding will often be not just the laziest but also the safest option.