Proof of that is that in languages where there are alternative patterns (like Python), people rarely create a factory, they use functions that return classes; they don't use singletons, they just use module static variables; they don't create observers, just just gather callbacks on a list; and so on.
There are many less formal patterns that do add a lot of value. And there are syntactic and type level patterns that are great, but typically OOP programs use those less than code in other paradigms. OOP has one common less formal pattern that is very useful and less used elsewhere - it's the abstract API, but this one people on the internet mostly recommend not using, because it requires inheritance.
Don't get too hung up on the implementation details in any particular language. A Python function that returns a class is just a factory by another name. The essential point is deferring the decision of which implementation class to instantiate until run time.
Inheritance is one way of handling abstract APIs, but not the only way (depending on language). And don't believe everything you read on the Internet. In some limited circumstances inheritance can be a great way to simply code and eliminate duplication, far outweighing any additional complexity it introduces.
Or just use interfaces. As in "design by contract".
And that's just common sense programming wise, not some OOP specific solution.
You can successfully apply OOP and OOP design-patterns to a lot of problems and come up with equally functional solutions as you would with FP.
And for certain domains, better.