Most people have a copy of DP and have not read the whole thing. Most people have read it in that they have read a couple pages, the table of contents, and a couple random patterns. To some extent that is how the book should be read: you have a problem that a DP solves and so you read the section on that pattern to get it right.
The problem is most people have a superficial knowledge of the patterns in the book (a list is easy to put together along with a short summary so most people have read one). They then go looking for how to apply the patterns to their domain so they can check the pattern box, without thinking about the large picture. They never consider that patterns exist to solve a specific problem and if you don't have that problem you shouldn't use the pattern.
The classic example is the singleton: it solves a tricky problem that large systems sometimes have. However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.
There are several patterns that are a specific way of creating a layer of abstraction. Abstraction layers are often very useful, but as the saying goes: "all problems in programing can be solved by adding a layer of abstraction - except too many layers of abstraction". I've seen cases of layers of abstraction that didn't solve any problems.
As such the original point: DP, by giving patterns names has created more harm than good. This is not the fault of the book though: the names were needed and the patterns are very useful when applied correctly. However before the book people would re-invent the patterns (badly) only when they needed the pattern.