I've found any change in the software I develop and sell can produce a "I don't like this change" response, whether it is removing features, changing features, or adding something.
As a software developer and producer, one needs to develop thick skin. If I make a change and one person complains, I need to remind myself that other people like it. However, if many people complain about a specific change, then I should listen, try to understand their perspective, and consider rolling back and/or adding an option to have things either the old way or the new way.
With the "add an option" approach, however, one must be careful not to gain lots and lots of UI-cluttering options in the Preferences.
The "add an option" approach can also result in more complicated customer support - users inadvertently turn off features/changes in the Preferences, and then wonder why things don't work. Support personnel have the added complication of working out whether the user has done this.
So there are a number of issues being balanced here: the customer's (or user's) dislike for change; the potentially real complaint that the change has worsened the software for some users; keeping the software flexible; but not drowning the user with too many unnecessary options; nor making customer support too complicated.