First, in most cases, FreeAndNil is a bit overkill. This is convenient when you free an object field outside its destructor or a global (ugly) variable. But most of the time, just calling is enough.
As you know, an object variable is actually a pointer to the data of the object. When you call Free, this buffer is freed (after the destructor starts, of course), but the Object variable still points to the newly freed memory position. It was called the Hanging Pointer. Having a sagging pointer is not a problem as long as you KNOW that it dangles in this context. For instance:
Procedure Myproc; var vString : TStringList; begin //Here, vString is "dangling" vString := TStringList.Create; //Here, vString is valid try //Do some stuff finally vString.Free; end; //Here, vString is "dangling"... But who care, it about to go out of scope and we won't use it again. end;
Calling FreeAndNil makes more sense in a global variable, where you don't know exactly when and how to free a variable. With that said, there is nothing wrong with calling FreeAndNil all the time (except for very tight loops where you try to get every ounce of performance).
Now, for COM objects ... As Mason said, they are counted. Therefore, if you keep a single reference to this interface, a call to MyInterface := nil; set him free. But when / if the variable goes out of scope, the compiler will take care of adding the cleanup code to make sure that the link to the interface is reduced. Therefore, if you are trying to keep the memory requirement to a minimum, set the interface to nil. Otherwise, it does not really matter.
As for your array ... You can just call Free on all the items in the list ... Optionally set them to zero after.