If a config file isn't deterministic (because it's executable and can read info from its environment), then it can be harder for tools to introspect on the full config (imagine an IDE showing your project's settings or a tool that validates it; the tool would be blind to what your config specifies in environments the tool doesn't test with) or know when it's safe to cache the config's result (because the tool doesn't necessarily know whether the environment may have changed in a way the config cares about). (Extreme example: if you had a software library that declared its list of dependencies in an executable config file, and that config file could arbitrarily read the environment, maybe toggling certain dependencies depending on your platform and whether you had certain pre-requisites on your system, then a package repository that the library is published on can't show a canonical list of the library's dependencies. When a user wants to install the library and its dependencies, the package repository server can't respond with library and its dependencies together, because the library's dependencies for you could only be found out by executing its executable dependency config on your computer specifically, so the server would need to send you the library, your computer would need run the dependency config, and then go back and ask the server for the dependencies, and then repeat for their depedencies, etc.)

Also, executable config files (deterministic or not) aren't so easy or pretty to programmatically modify. If the config file can define arbitrary functions and use them to compute the config, then if you want to tweak the config with a tool like an IDE or package manager, then it will need to try to recognize a pattern in the config file, or add a chunk of code at the bottom that just mutates the config file after your handwritten code.