While writing code and refactoring, it is very easy to introduce knowledge duplication.
D. Thomas and A. Hunt state in their book The Pragmatic Programmer that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Knowledge duplication has a negative impact on the maintenance process. Since the encapsulated knowledge is split among many places in the code base, changing functionality in one place, means updating the rest as well. We should not divide the functionality behind the unit of knowledge among many places and in many formats, but it should be represented in one place only.
We should apply the DRY principle not only when thinking about lines of code, but more about units of knowledge. This is because not all code duplication is necessarily knowledge duplication. If 2 different pieces of knowledge are implemented in the same way it does now mean we deal with code duplication. Each piece of code represents different knowledge.
A use case where knowledge duplication occurs is between an API and a service that consumes the API: documentation, API client, mock APIs, new representations of data sources etc. This knowledge between the 2 services needs to be kept in sync. When the API response structure for an URL call changes, the data structure in the consuming service also needs to be updated. This duplication cannot be avoided, but there are tools out there that automatically generate such consuming resources.