The number of repetitions is a red herring. It's more a question of which business flows the code adheres to, and what's the likelihood that a change in one should also affect a change in the others. Often this is a gray distinction and it amounts to a judgement call about what type of changes and what mindset will the maintainer come in with in the future. I'd like to think that with experience I've gotten much better at this, but it's exceedingly hard to get anything besides infrequent anecdotal evidence. Working on the same code base for 5 years, every once in a while I get the joy that comes with discovering that I made a good decision years ago, beating the YAGNI odds or leaving a particularly relevant comment that saved me significant re-investigation of a difficult issue.

But how could studies on this type of long-term maintainability draw meaningful conclusions? It just seems incredibly intractable from a scientific perspective—a result of experience and thoughtful consideration outweighing formal, documented and trainable techniques.