Yes, I agree that DRY is not the only principle that will help your code to be more extendable. You need to follow the SOLID principle.
But the example you gave, is the pure separation of knowledge. As I already mentioned above, there can be duplicate codes that don't violate the DRY principle. Your example perfectly fits there.
Maybe two endpoints can have similar nested POJOs but their knowledge is different. They are defining different logic. You should be creating multiple POJO objects for similar responses.
Thanks for poniting it out Michał Dobrzanski.
No thanks for sharing.
DRY does not pay off in large codebases and this tutorial overly simplifies the case.
Let's say there are some backend endpoints and they are using nested objects inside JSON schema. It is perfectly fine to duplicate POJO objects when reading. If we are coding a mobile client and we work simultaneously with backend team, then it is better to adapt response in one place, than using the same shared object in others. Some response might change and this will require the whole POJO to be split and refactored.
Let's say we use the same function in many classes. The only solution is to use the composition and wrap the function in a class and pass it as dependency.
More shared code = more coupling.
You forgot about a more important rule - make codebase easy to extend, not modify - the Open/Closed Principle. Simple DRY is not enough and is an oversimplification.