Traditional OOP/Imperative programming tends to encourage this "reinvention". Where the old guard goes? I think programmers age out when they see the same "trend" for the 3rd time and decide they need to get off the hamster wheel and go into management. GoF patterns make sense if your language is statically typed and OO and you don't have real data abstraction.
To be fair, most OOP practitioners don't even know what "data abstraction" means: this is what is meant by "it's better to have 100 functions that work on one datastructure than 10 functions that work on 10 different datastructure. The latter is OO, the former is FP.
Your first paragraph makes some sense, but I truly disagree with your second.
Good OOP design is very similar, if not identical, to good FP design. For example:
- The iterator pattern: is essential to more abstract FP, see for instance 'the essence of the iterator pattern: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.... The iterator as a stream is a coinductive data structure and a such a fundamental structure in FP. Also note that transformations on iterators are applicative.
Then, look at many of the other GoF structures: the visitor pattern, which is very similar to recursive algorithms on trees. The adapter is basically applicative, the Factory is difficult, but could be seen as a coinductive structure.
Also, one should note that in (modern) proper OOP, composition is your most important tool. This is very similar to composition of functions.
You picked an especially bad pattern for your proof. Iterators aren't inherently functional. In the imperative world they needlessly maintain state and are by nature one giant side effect. Data abstraction doesn't even require an iterator "pattern" to achieve iteration, that's the whole point of data abstraction that a "pattern" isn't required but merely a "concept". In Clojure, for example, the concept is a sequence which has stateless traversal. That paper you quote even makes the distinction between the separate approaches taken from functional versus imperative.
To be fair, most OOP practitioners don't even know what "data abstraction" means: this is what is meant by "it's better to have 100 functions that work on one datastructure than 10 functions that work on 10 different datastructure. The latter is OO, the former is FP.