An insightful comment, but to be fair many important GoF design patterns like Composite and Decorator are genuinely object oriented, leveraging polymorphism and interfaces to produce order and elegance.
Object-oriented order and elegance compared to an object-infested mess of special cases and complications. Remember that 25 years ago C++ wasn't a pleasant place and Design Patterns was an impressive step forward.
Oh, I do remember the grim story really well. I was there. I still have all the books. And the scars.
Back then I was a young innocent programming soul trying to reconcile C++ and GoF and UML and all that. And Modern C++ Design. And const here const there const copy constructor by reference.
I spent about 12 years doing C++ at the very peak of its OOP hype and did the same... then finally left, certain that I would hate doing "real" work in any other language, and a funny thing happened...
I realized I was suffering from severe Stockholm Syndrome. Node.js was just.... so gd easy to do anything in. Maybe too easy (a la leftpad), but build/deploy cycles were instantaneous, adding new libraries was easy- again maybe too easy, JS has a tiny fraction of the footguns and you don't have to know them all to write code that isn't going to blow up on you or cause memory leaks and performance issues.
Python... was the same. I have even taken some dives into Java, and while I don't love the architectural monuments Java devs tend to produce, its still less of a hassle than C++.
I was so happy when there was a move towards templates and data oriented design and the priests of OOP were getting knocked off their pedestals- for a period you were at risk of getting shunned for not kneeling at the gods of OOP and the GOF book and UML diagrams.
I remember arguing for years with my father (also a programmer) about him writing either vanilla C, or writing C++ in (what would become) the data-oriented style.
...and look at me now!
I collect things in arrays, with no objects, preferrably in pure C. No classes, no objects, just arrays and transforming functions everywhere.
FP languages have their own patterns. Some of them can be plausibly cast as "fixing weaknesses" in them, too.
Multiparadigm languages end up with lots of patterns you need to learn, because while multiparadigm languages may support many approaches to a given problem, generally there are definitely better and worse approaches, specific to the language in question, and between the number of options, the subtly of their implementation details and how those interact with the problem, and the specific preferences of the language itself (because all multiparadigm languages still have preferences), it can take a multiparadigm language community a decade to work out the best pattern for a given task. The existence of many options inevitably expands the number of wrong options, or if you prefer, "distinctly suboptimal" options, as well.
