Quite simple, why would I want to write code that works for all cases and scalable data when all I need to do is repeat the same process a few times with a few minor tweaks? 

I'm unlikely to need to edit this again any time soon.

It looks like a lot of less work to just go...

function doStuff1(){/*.a.*/}
function doStuff2(){/*.b.*/}
function doStuff3(){/*.c.*/}


And if I ever need to add something...

function doStuff4(){/*.d.*/}


And if I need to remove it, I remove it.

It's harder to figure out how to make all of those into one straight-forward pattern that I can just feed data into and deal with all the cases, and make a bunch of changes I don't feel like I'm ever going to have to do.

Why be DRY when it looks like a quick cut+paste is going to be so much less work?

If you repeat yourself, you can create maintainability issues. If doStuff1-3 all have similarly structured code and you fix a problem in one, you could easily forget to fix the problem in other places. Also, if you have to add a new case to handle, you can simply pass different parameters into one function rather than copy-pasting all over the place.

However, DRY is often taken to an extreme by clever programmers. Sometimes to not repeat yourself you have to create abstractions so obtuse that your teammates cannot follow them. Sometimes the structure of two things is only vaguely similar but different enough. If doStuff1-4 are different enough such that refactoring them to not repeat yourself causes you to have to write unnatural code or undergo clever coding backflips that will cause your team to glare at you, then it may be ok to repeat yourself. I've bent over backwards to not repeat myself a couple of times in unnatural ways and regretted the end product.

I always err on the side of DRY, in the rare case repeating myself when I think that the benefits in readability are worth the risks of someone forgetting to fix a bug in multiple places.

Taking that advice into account, it sounds like in your case


  repeat the same process a few times with a few minor tweaks


I would definitely work hard to not repeat myself in your case. Assuming minimal "tweaks" -- they can be handled with different parameters that impact the behavior or perhaps dependancy-injected to perform different subtasks.


  Why be DRY when it looks like a quick cut+paste is going to be so much less work?


Famous last words. You will regret thinking that when a junior engineer tweaks/fixes/refactors one doStuff and doesn't even realize the others exists. Hilarity ensues. No mostly heartburn ensues. Every line of code costs more. How many code paths must you test with so many repeated functions? If one function, you just have to test one main path with a few behavioral modifications. If copy-pasted you have to test every doStuff separately. Odds are you'll miss one and a customer may have an unwelcome bug and you may have some unwelcome emails in your inbox.
