Factory Design Pattern - Why Interface necessary?

You can always apply a design pattern in the way you like. There is nothing wrong with deleting an interface. You should however take into account that deleting the interface leads to a less general structure.

You use the factory pattern because you don't want your calling code (main function) to know anything about the construction details. You don't want to know what a FordFiest is. You just want a car in general to be built. If it is a Ford Fiesta, then so be it. This detail is something the factory (and its subclasses) should handle. Right?

If you don't want your code to depend on the specific factory, you need an extra abstraction layer, provided by the interface, leading to "decoupling" the two parts. If you don't mind your code binding to the specific factory implementation, you could always remove the interface.

Hope I helped!

The interface (or abstract factory base class, which is essentially the same as an interface in effect) is useful whenever the caller of the factory does not know the type of the factory.

You provided the base for your own practical example, so I'll add my explanation here why that's not only useful when having a list of factories:

Imagine a method that is supposed to create a car when appropriate, without knowing what type of car to create (that is decided by the factory implementation). The method looks at a Person object, which has an OwnsCar property, and that property ultimately decides whether the factory method should be called:

public Car CreateCarForPerson(Person person, ICreateCars carType)
{
    if (person.OwnsCar) {
        return carType.CreateCar("red");
    } else {
        return null;
    }
}

In the same way, you could also use such a factory to create an arbitrary number of cars:

public Car[] CreateAnyNumberOfCars(ICreateCars carType)
{
    var result = new List<Car>();
    for (int i = new Random().Next(100); i >= 0; i--) {
        result.Add(carType.CreateCar("blue"));
    }
    return result.ToArray();
}

Note how none of these two methods knows what car type is being created; they use a factory of whom they only know the interface, but not the exact type.

So, if you want to be able to supply different factory implementations, you can declare a common interface for your factories. If your factory only serves to keep your callers away from direct invocations of the target constructor, you do not need the factory interface.

Sure you could use CarFactory to create derived car classes, but then everyone who wants to support the creation of cars has to derive from CarFactory. It seems to me that the purpose of the interface is to allow more flexibility in who can act as a car factory. The notion is that all you need to do to be a CarFactory in this example is to implement the ICreateCars interface. No need to introduce the overhead of the delivered CarFactory base class.

The key is in deciding what your parameter type will be on functions that accept a Car Factory. (or what the member type will be for a member that stores a CarFactory) If you use ICreateCars, then anyone who wants to create cars need only implement the interface. If your parameter type is CarFactory, then they would have to inherit from CarFactory.