The main value of the design patterns is that they have given names to things that were already common and fairly intuitive to a half decent programmer.
But I've come across many people trying to use them as a guide for how to write code - and misunderstanding them. Factory in particular is often misunderstood. It is mainly useful when you have parallel class hierarchies not as some odd wrapper around all the constructors in the software.
Don't underestimate the power of naming things. If you can't name a paradigm you used then your solution is just something that does the job.
The value of design patterns and giving them appropriate name is to have a common language, a basis for communication. Sharing ideas or giving instructions is much simpler when you can actually name something with a few words.
I'm not sure what you mean by parallel class hierarchies. I use a factory if I have a class that needs to be able to make an instance of some other class, but shouldn't know about how to construct it (i.e. it doesn't need to know about the dependencies that other class might need to function).
I also do not understand "parallel class hierarchies".
Here is another use case for a factory: Building an AST data structure in a compiler. There are nodes to represent Constants, Addition, FunctionCalls, etc and you have to build a tree structure, which represents a program.
Now consider the case, where you build the addition of two constants ("36 + 6"). Using constructors, it could like like: new Add(new Const("36"), new Const("6"));
Using a factory: f.newAdd(f.newConst("36"), f.newConst("6"))
The advantage of the factory is that it can optimize on the fly and return a Const("42") node instead of an Add.
To be a cool compiler, you don't want to optimize this in the AST building phase. The user may be running in a mode of printing the AST only, to e.g. implement their own autocompletion. This code obfuscates the truth by doing this.
I remember that at some point gcc -O 0 was doing exactly that and it is pretty irritating if you write a decompiler and want to test it. Fortunately clang does it properly.
I shouldn't speak for the OP, but I think they are referring to the fact that the factory pattern very naturally shows up when you also have the bridge pattern. You have 2 (or more) parallel class hierarchies and you need a way to construct the objects from the correct hierarchy.
You are also correct that it happens in other places too. Some people overuse it, though. They abstract out the construction of their objects for no reason at all. You already have a constructor -- usually there no need to have an object that contains all the constructors.
You have to be more clear with your terminology. The thing you are talking about is called "Factory Method Pattern". Don't call it just "Factory Pattern" because it is not really a factory. Instead it uses a factory to achieve a very specific goal.
The Abstract Factory Pattern is one of those patterns which I never fully understood because I never found a good real-world example which relates to my line of work. That's the reason why I misunderstood you ;)
I don't really see what you call a "Simple Factory" as being covered in the Gang of four book. I should have been clear about meaning Factory Method but the terminology is often apparent in class naming. So for the "Abstract Factory" pattern, I would use "Kit" in class naming. I would reserve "Factory" for the "Factory Method" pattern. Pointlessly wrapping constructors in a separate class and calling it a factory doesn't really get you anything. Neither does contriving a parallel hierarchy to pointlessly allow the use of the "Factory Method" pattern - something that I have also seen.
But I've come across many people trying to use them as a guide for how to write code - and misunderstanding them. Factory in particular is often misunderstood. It is mainly useful when you have parallel class hierarchies not as some odd wrapper around all the constructors in the software.