One of Abstract factory pattern benefits is to avoid conditional logic of Factory pattern. However, such approach plods more classes, more code, more units tests and does not make code neither quicker nor readable, so as code class diagrams or documentation. So, what's the point in not having conditional logic on Factory pattern in such a case?
In OOP there is a general "goal" to replace conditional logic (if-else,switch etc) with polymorphism. This usually involves creating an abstract class or interface and creating the range of objects you might need from there.
The benefit is that new derived classes can be added, without adding new code. The canonical example is different shape classes (square, circle, triangle etc) all derived from a base Shape class. Each new shape provides its own implementation of draw() for example.
The same applies in Abstract Factory whose purpose is to provide multiple "sets of objects" to a component or similar. The canonical (contrived) example is providing the correct set of UI objects for an application to work under Windows, Mac, X windows etc. The idea is to pass the correct factory object to the application and allow it to create the correct set of set of UI objects that it needs for the target environment.
Without this construct the application would need to be passed a parameter like "Windows" and the use the "dreaded" conditional logic to determine which objects to create using Factory Methods.
Most people will agree that if the number of "sets of objects" is small and fixed, then go ahead and use conditional logic and factory methods. But if that situation changes then you are faced with code changes.
If you use Abstract Factory to add a new "set of objects" you only have to create a new subclass of your Abstract Factory and not change your application code. This is more readable and more extendable, highly regarded attributes in large systems.
That is "the point in not having conditional logic on Factory pattern" but always judge in the context of your own business needs.