I think it's a case based system, where the team has to decide. Sometime it's way easier to decide as a team to just follow a convention and if you got code reviews and a good culture that's a good thing
however as soon as you move outside of your scope of ownership a.k.a libraries I always go for configuration over convention, but always with a working default set with 'expected' default behaviour.
As you mention the problem is the complexity of configuration and the abstraction of configuration. This where I go for domain driven approaches so my model orients towards the user.
For an ops guy I write different configurations than for a dev guy for example. The medium also differs, ini, toml, yml, env based on the application and it's intended users / usecase.
very often I build hook systems that integrate with each other so you have the flexibility of using env variables but you can have a local conf file as well.
It's a usecase debate in my opinion with the main focus: who are the people who use it.
Also if I remember correct in the book there is the point about generative code. If you go for configuration the code should be generated from the configuration / definition.