Yes, true, it depends. One exaggerated example. Lets imagine we use the following in the code (coders duplicated the previous line and changed):

a1 = 1

a2 = 2

a3 = 3

Then someone had an idea, that using underscore is better, so according to the small improvement logic the code will become (note, that we did not bother with refactoring here, just introducing a new example as I argued):

a1 = 1

a2 = 2

a3 = 3

a_4 = 4

a_5 = 5

Now, I argue that without using intermediate refactoring it is quicker to refactor to the following “when we have time”:

a = [1, 2, 3, 4, 5]

because of more regularity in it. And in real life the sequence will continue using new and old style for developers seem to find examples to copy-paste more or less randomly…

It is easier to remember “best practices” when you work alone or at least review everything, so you can refer to the current exemplar code. (It is also possible to point to an example when discussing solution, but some devs can be unhappy they are told what to do and/or will always expect to be told)

To reiterate, sometimes (but not always) it makes life easier to just gather 2–3 simple, dumb, but uniform copy-paste artifacts, before starting to refactor or even change that to some better intermediate form if it is known (as in example above) that number-postfixed variables needs to be gathered to a list/array rather than have underscore.

The above example highlights another thing. The single

a1 = 1

does not yet justify refactoring to

a = [1]

unless the problem domain clearly points to that. And sometimes stakeholders/managers try to be helpful and tell “the requirement is just one for now”.

With the above, I wanted to highlight how nuanced refactoring and improvements decisions can get.

Using separation of concerns helps a lot, but some concerns emerge / are discovered only later in the lifecycle.

One more tool to approach the same problem in addition to "filtration" is to consciously build "mini-frameworks" as described in one of my recent posts: https://medium.com/star-gazers/framework-as-a-way-to-painless-software-development-c3382f35a334