Config files suck for three main reasons.
Config files suck because learning useless things sucks. Most config files follow their own definition format. This results in ephemeral information being learned and very quickly forgotten. Often this process repeats a few times for pieces of software that require reconfiguration to meet the expectations of the user.
The time spent understanding the DSL of the config file would likely be better spent writing code in a proper programming language. There are two primary benefits to this. First, it builds on prior experience. If you are skilled at writing C code your ability to understand and configure software that is configured in C is improved by this prior knowledge. Second, by doing this process of configuration you are learning information that is likely less ephemeral. There are only a few good programming languages and by programming in them your proficiency in using them increases.
Consider my dotfiles [1]. There are three files in my dotfiles that don’t reside in the XDG_CONFIG_HOME directory. These three files are my .bashrc, my .Xresources, and my .xinitrc files. I have these in my XDG_CONFIG_HOME directory and symlink to them from their expected locations because the programs don’t respect the XDG_CONFIG_HOME directory specification. This is annoying to setup on each system I use. A simple solution to this is to not use software that doesn’t respect the spec, but when Xorg and Bash don’t respect the spec, it becomes a bit more difficult to do so.
The bigger issue is that the disconnect between the configuration of software and source code results in multiple sources of information contributing to the configuration of a software program. This is annoying because to achieve the same program configuration across systems one must ensure two different locations are synchronized instead of one.
Config files often don’t allow for large changes to be made to programs. The changes that can be made are constrained to what is deemed reasonable by the developers of the software. This is not similar to proprietary software where the developers actively hinder the freedom of users, but by having the source code and the configuration done in the same location, you can fundamentally change the operation of the program without jumping between different locations.
As I see it, config files are worthwhile if users are expected not to build from source. This may be the case for many open source projects, but I personally dislike using software in this way. This is a matter of opinion, but I think one of the most valuable parts free software is the freedom to change the source code as I see fit. By distributing software with config files, this sends an implicit message to users that they are expected to use the software as is, without modifying the source code.
If you don’t see a reason to build from source, it is your right to continue using config files. If you are building a project where you want users to configure, extend, and customize their computing experience to the fullest extent, consider doing away with config files as it forces users to directly manipulate your codebase, giving them more autonomy and flexibility. This may hinder mass adoption, but is that why you build software? It’s not why I do.