To my experience, the most important factor here is not necessarily a technically one, but an organizational: the number of teams and developers who are available for the maintenance of such a system. 

- In case there is only one small team who has to serve several customers, keeping the code as DRY as possible should be the top goal. Avoiding copy-paste programming as much as possible helps to keep the team out of maintenance hell in the long run. Fortunately, OOP, functional programming, and other techniques have equipped us with more tools than just if-else orgies to make certain code configurable.

- In case there there are different teams, maybe one responsible for customer X, one for customer Y, having each team maintaining different variants of the same module is much more acceptable than for a single team (and sometimes, it is even more desirable, since it can reduce the communication overhead between the teams and the need to invest effort into integrating different, conflicting customer wishes).

Of course, the former is a simplification. Even for a small team, it can sometimes make sense to copy a certain module and create customer-specific variants - it depends heavily on the individual set of requirements for the module. And even when there are multiple teams, it will make sense to keep certain core modules general and configurable, so they can be reused in an unmodified fashion for several different customers. For both cases, the key point is to separate modules which may be customer specific from the ones which should stay general, and that is the real software engineering challenge.

Is there empirical evidence for this? Sure, look at all the forks of different Open Source projects - wherever one produces such a fork of a "living" project, they are effectively copying the code and maintaining the code as a new team, with the goal of making a variant for a new user group ("customer"). This happens regularly from the smallest projects up to the largest ones (look at the the tons of different Linux distributions and their responsible teams, this is probably one of the most prominent examples). Though those teams are clearly violating the DRY principle to some degree, it does not necessarily cause big maintenance issues, at least not issues which cannot be handled by a professional team.