Because it isn't. Garbage collection is something that happens at run time by a garbage collector via an algorithm like mark-and-sweep, tri-colour marking, etc, and as a block of code that's called at runtime it A) has a lot of information about your program and B) has a nontrivial performance impact.
Unfortunately I can't talk specifics (stupid NDA), but schrototo has said that it's a compiler-level feature, which would automatically disqualify it as being a bona fide garbage collector.
Speaking generically, any static feature is going to a great deal less powerful than its dynamic equivalent. Thinking of compile-time memory management as garbage collection is not just a leaky abstraction, it's a broken water main flooding into the street.
Think less "auto pilot" and more "cruise control". You still have to understand the accelerator and the break, you just don't have to use them as much.
Automatic garbage collection doesn't even require a garbage collector -- the monolithic piece of code that performs the scanning and reclamation of objects -- it simply requires freeing the programmer from the task of managing the storage of an object. Fancy collector algorithms are meant to improve throughput and latency -- you could definitely create an implementation of Java that uses automatic reference counting but you'd be searching for something faster really quickly.
If I have a language where I create a number of managed objects and the compiler's escape analysis determines that these objects never leave the function's scope and so changes them to be an alloca then you would have garbage collection without involving a garbage collector.
Again, if that's what automatic reference counting is as sold by Apple then I'd consider it to be garbage collection.
(I haven't done any Mac OS programming with GC, so I really don't know anything about it, but I've always heard people say the GC is not all that great. So my own uneducated guess is that while GC is messy and complicated, ARC is simple & doesn't have any runtime overhead (they say in the docs that retain/release is now much faster, as is autorelease using the new syntax).)
Can you back that up? I'd like to see a source that disconnects garbage collection the feature from a runtime garbage collector the implementation of that feature.
Independent of the semantic dispute, I don't think you understand what ARC, the iOS 5 feature, actually is. It's not a technology that "frees the programmer from the task of managing the storage for an object". Just to start with, that is a decision that can only be made at runtime, and as has been discussed ARC is a static-time feature.
These two things unfortunately share a name, but absolutely nothing else. The iOS 5 feature is not, and has no relationship to, and does nothing remotely like, the garbage collection algorithm with the same name.
(The same logic applies to longer "cycles" of references --- if A refers to B refers to C refers to D refers to A, then none of the objects in the cycle can be collected first, and they all stick around.)
In CPython, by the way, there is a separate garbage collector, which runs periodically to detect and mop up cyclic structures. Other implementations --- Jython and PyPy --- don't use reference counting to begin with.
(This is a point of definition independent of the subject at hand. Refcounting simply is a form of GC. Imperfect for most languages and many datatypes but GC all the same.)
http://docs.python.org/library/gc.html
Since the collector supplements the reference counting already used in Python, you can disable the collector if you are sure your program does not create reference cycles. Automatic collection can be disabled by calling gc.disable().