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.