This is always an interesting conversation. I have had similar discussions in several jobs.
My personal style is to refactor everything within an inch of its life, and ruthlessly remove duplication. I have found, however, that this approach can occasionally increase rather than decrease future maintenance work. The key point for me is not to simply assume that the benefits of separating and factoring everything are always obvious. Or even always valid.
For example. One part of our product has a core section, common to all customers, but each customer also has a "skin", comprising both customer-specific behaviour and look-and-feel templates. A common way to set up for a new customer is to copy the "skin" from an existing customer, then modify it as we learn and agree what the new customer needs. Experience has shown that customer "skins" are usually different enough that attempting to eliminate every duplication and share common aspects between them only ends up costing more development effort to split them apart again when they inevitably differ.
So, here's a strategy to sort this out in your case:
First, find out about the usual development tasks performed by the "copy-n-paste" people. Is their work part of a single growing "core" codebase, or is each piece a separate chunk, perhaps for a separate customer?
Then find out about the people, skills, management and hiring process. Are such developers expected to work together on a core product, or do they work alone on their own bits? Are developers moved about, hired and fired at will, and expected to pick up each small task without understanding the rest of the system? Is the system understandable and self-documenting or is it a ball of confusion?
All of these factors can influence whether refactoring to remove duplication, or duplicating to increase independent clarity is a "survival skill".
Eventually you should find yourself in a position where you can help the organisation realise that duplication suits a small range of circumstances, but refactoring to eliminate duplication (in my experience, at least) suits a much wider range. With that understanding in place, choosing whether to duplicate or refactor can begin to be done based on parts of the system, rather than individual preference.
Does that help at all?