FreeAndNil almost always simply hides bad programming. You should almost never need it in a well written program. The fpc/lazarus community seems to favor it, The Delphi community seems to use it with more caution.
Well, it depends. Like, if you want the intersection of two StringLists:
function Both(List1, List2: TStringList): TStringList;
Obvious and easy, right? But now there are three objects that have to be freed at some point. It's clear the caller has to do that, right? But that's not where it is created. So, inserting the matching Free immediately afterwards typing the Create doesn't work.
function Both(List1, List2: string): string;
How about this? Use the TStringList.Text property. But that requires strings without line breaks. And there is more overhead.
function Both(List1, List2: TStringArray): TStringArray;
How about this? Still overhead, but at least you don't have to Free them.
function Both(List1, List2: TStringList; out These: TStringList): Boolean;
Many people think this is the way to do it. That way, the caller has to Create and Free all of them. I sometimes do this, if it is important to return a clear status, but I really don't like it. Useful in C++ style where everything generates an exception, but not in Borland style, where nil or Count = 0 are used.
If you have a class that has a property that is another class, it should be obvious that you shouldn't free it outside the encapsulating class. But you could. And it is not easy to make a copy, so you keep passing around pointers to that same class instance, or make more of the encapsulating one. Many also allow you to assign those property classes. So when do you free what if you assign the property of one to another?
It is interesting to know that Delphi dropped ARC, which is a form of global automatic memory management that does not rely on garbage collection.
I vastly prefer refcounting to garbage collection, because it keeps memory usage in check and doesn't periodically freeze your application. But I'll see if I can use the TInterfacedObject.