If breaking DRY can simplify things then there is almost certainly a problem somewhere.
It might be in your application, design decisions, the framework being used or the language itself. It may not be practically feasible to solve it given time constraints/business requirements etc. but there is almost always a 'technically' better option.
A simple example is java annotations - They are not easily composable/abstractable. It is a limitation with java - but can be partly mitigated (as the author points out) through better design practices. It is also possible to switch to a sufficiently dynamic language (eg. ruby) or a language having sufficiently advanced hygenic macro system (eg. Rust), where you have this level of flexibility - but it might not be a good idea because of existing investment in the technology.
Another example is CSS rules - You can modularize at selector level but from a maintenance perspective it would be a lot easier to keep code DRY (through multiple design iterations) if you could modularize at a more abstract level (functions, mixins etc.) and later associate them with selectors. Here CSS pre-processors can help and you can additional dependencies like Sass/postcss on top of your existing stack to enforce DRY.
To keep our application behaviour deterministic we want to make sure that we only have 1 place where certain things are happening.
Like having only one query function instead of 14 in different files with slightly different behaviour.
The ideal approach would be to start with very small functions (1-2 lines) that do very specific things (SRP), and then compose them to get other functions/services that have higher level responsibilities. In this case even if you eventually realize that your higher level functions are not suited for some edge case - you can "peel off" layers of abstraction downwards till you get a function that is sufficiently low-level.
A hypothetical example:
queryDB(sqlTemplate, params)
^
|
queryDB(sqlTemplateFileName, params)
^
|
queryDB(repository, params)
^
|
queryProducts(params)
You do end up with a lot of functions, but there is nothing wrong (or less DRY) with it.