I'd think most will agree that vscode is a sufficiently advanced project to serve as example.
It keeps the two concerns apart - configuration is configuration and extension is extension. This allows it to offer excellent configuration features in a declarative way and enjoy all the benefits that a declarative style brings - there's an editor that knows all the possible config options, you get completion support for the values, there's a finite and well-defined set of things you can do which makes it easy to understand etc etc. It's just nice, and you need neither documentation, manuals or special knowledge to get going. For the special cases that you need something more, you have an extension / plugin model. The plugin contains the logic of the configuration, and the configuration contains.. well.. the configuration. Doing it this way allows you to focus on creating a nice extension api without having to consider the constraints of what a nice config file/syntax would look like. This is where scripts and the like shine. Both the config camp and the extension camp benefit. The key here is that you have to separate systems that each are more simple and well defined, instead of spaghetti:ing everything into the same bowl. Both declarative and imperative styles have advantages and disadvantages - their relative usefulness is contextual to the specific problem. There's nothing corporate about this, just plain common software engineering sense. You'll find it in the pragmatic programmer from years ago, and it still holds true today.
