I almost always reject changes which add a new configuration option, setting or preference. It is usually much easier to get a change upstream if it does not add an option than if it does.

Options make the software harder for me to test. I have to go fiddle with the options every time I touch related code and make sure all of the branches work.

Options are often a symptom of poor product design. Designing a good software product is hard; building a lowest-common-denominator product with a lot of options is relatively easy. But this is a worse product, and worse for everyone in the long run, and not the kind of software I want to build. In my experience, it is rare that adding an option is the best solution to a problem.

Options make the software worse for most other users, too -- particularly, they make it harder for new users to install and configure the software. We have too many options today and intend to reduce the number of options over time.

Generally, changes which introduce options are really easy to write and really hard to maintain. Since I will be the one maintaining them, changes which introduce options face an exceedingly high barrier to upstream adoption.