You are right - copy-paste works great, and DRY has no point when your task is to produce a program for which either the copied template or the copy will not have to be maintained or evolved in the future. When those two software components have a completely different life cycle, then coupling them together by refactoring common code into a common lib which is itself under heavy development can indeed have unpredictable effects for the effort. On the other hand, when copying code sections inside one program or program system, all these parts will typically have the same life cycle. I will illustrate below what this means to DRY and project management.
Seriously, there are lot of such programs out there: for example, the computer game industry produces lots of programs which have to be maintained over a short period of some months or a year at maximum, and when that time is over, copy-pasting old code from a previous game where the maintenance period is exceeeded, into a new game's code base is perfectly fine and might speed things up.
Unfortunately, the life cycle of the most programs I had to deal with over the last years is very different from that. 98% of the requirements or bug fix requests which arrived me were change requests for existing programs. And whenever you need to change something in an existing piece of software, "project management" or planning works best when your testing and debugging efforts are quite low - which will not be the case if you change something in one place, but due to copy-pasted business logic you easily forget you need to change a dozen other places in the code base as well. And even if you manage to find all those places, the time to change them all (and test the changes) is probably much higher as if you have only one place to change. So even you could make an accurate estimation for the change, having the costs a dozen times higher than it needs to be can easily collide with the project's budget.
TLDR - whenever you develop a program where is no necessity or responsibility for bugfixing and maintenance of the original or the copy, feel free to copy. But if you, your team or your company is or might become responsible, apply DRY whenever you can.
As an addendum, let me explain what "bugfixing and maintenance" means, and how this leads to unpredictability in planning, especially inside one product, by a real-world example. I have indeed seen these kinds of things happen in reality, probably not with 100 instances, but the problems can even start when you have just one duplicate instance.
The task: create 100 different reports for an application, each report looking very similar, some requirement differences between the reports, some different logic, but all in all, not many differences.
The dev who gets this task creates the first one (lets say it takes 3 days), after some changes or minor bug fixes due to QA and customer inspection its finished, it seems to run fine. Then he started to create the next report by copy-pasting and modifying the whole thing, then the next, and for each new report he needs ~1 day in average. Very predictable, at a first glance ...
Now, after the 100 reports are "ready", the program goes to real production, and some problems occur which were overlooked during QA. Maybe there are performance problems, maybe the reports crash on a regular basis, maybe other things do not work as intended. Now, when the DRY principle had been applied, 90% of those problems could be solved by changing the code base in one place. But due to the copy-paste approach, the problem has to be solved 100 times instead of once. And due to the changes already applied from one report to another, the dev cannot quickly copy-paste the fix for the first report to the other 99. He has to look into all the 100 reports, read them, translate the change to the modified report, test it, and maybe debug each of it individually. For the PM, this starts getting really hard - he can of course take the time for a "regular" bug fix (lets say, 3 hours) and multiply this by 100, but actually, this is most probably a wrong estimation, some of the fixes might be easier to make than others, others might be harder. And even if this estimation is correct, having the debugging costs 100 times as high as they needed to be will cost you company a lot of money.
The same will happen the next time when the customer asks for changing the color of his company emblem in all those reports, for making the page size configurable, or by some other new requirement which affects all reports in a similar manner. So if that happens, you can make an estimation for the costs and bill the customer 100 times the price he would have to pay when the code had been DRY. However, try this a few times and then the customer will cancel the project because he will probably not be willing to pay your exorbitant evolvement costs. And maybe at that point someone will ask the question why this happened and point with the finger at the person who made the decision for this copy-paste programming.
My point is: when you produce software for others, you have always at least for a short period of time the responsibility of making the thing work, fixing bugs, adapt the program to changing requirements etc. Even in a green-field project, these parts can quickly add up to far more than initially planned development effort. And especially when all your copy-pasted code is inside one product, the period of time of responsibility is for all parts the same, which is quite different from the situation where you copy-pasted some older code from a dead project which is no longer under active maintenance.