This article is from the Object-Oriented Technology FAQ, by Bob Hathaway email@example.com with numerous contributions by others.
There are several reasons why true object-oriented programming requires garbage
1. Manual Memory Management Breaks Encapsulation.
Program components frequently need knowledge of an entire program to
determine the last use of an object and provide deletion. This makes reuse
of the component nearly impossible. For example, methods and functions
taking a container as an argument need to know of or make assumptions
about the rest of the program to determine ownership of the objects in the
Attempts to encapsulate memory management with reference counting, the "poor
man's garbage collector", are usually misguided. Reference counting has worse
performance than GC, awkward syntax, and poor semantics, which typically
include failure to reclaim cycles, inability to handle stack and static
objects, lack of polymorphism, and problems with interior pointers (e.g.
arrays and multiple inheritance). Intensive research  in garbage
collection has completely solved the above problems and made reference
counting an inadequate substitute for true GC.
2. Implementation Hiding is not Compatible with Manual Memory Management
Implementation hiding is a pillar of object-oriented programming,
but explicit memory management requires implementation-dependent
low-level knowledge of how memory is structured. For example, programmers
often use "copy on write" to efficiently implement pass-by-value semantics.
However, to manage memory explicitly, a program has to know if it has a copy
of an object or the object itself. Programmers sometimes use reference
counting to encapsulate copy-on-write memory management. However, this only
works well in simple cases like strings where the data is not polymorphic
and does not contain pointers.
3. Message Passing Leads to Dynamic Execution Paths
Manual memory management must make assumptions about a program's order of
execution to make a compile-time determination of the last user of an
object. While this is often possible in procedural languages, the object-
oriented paradigm of objects sending messages to each other (possibly from
different threads) makes it impossible to statically determine the last user
of an object. For example, event driven GUI programs frequently have no
clear order of execution. Other dynamic control structures, such as
exceptions, also make static analysis of memory usage at compile-time
4. Differing Memory Management Schemes Hinder Reuse
Because no memory management scheme is universal enough for all applications,
manually managed components and libraries often use incompatible memory
management schemes. For example, there are common container libraries using
each of the following schemes:
a) Doubly specified empty and remove methods with one including a memory
delete, placing the memory management burden on the client, who must call
the appropriate method.
b) Switches indicating deletion. Many applications must clear the switch to
support long-lived data and keep track of ownership of data shared by
multiple containers, leaving many memory management issues unaddressed.
c) Value semantics store objects rather than references, inhibiting data
sharing and carrying expensive performance costs when complex objects are
copied by value.
d) Reference counting, which was already discussed.
Any components or libraries that use containers with different memory
management strategies are difficult to use with each other.
5. Garbage Collection Works
It is not enough to merely find fault with manual memory management. One also
has to show that garbage collection provides a better alternative. Early
versions of garbage collection were merely crude implementations of
mark-and-sweep that left much to be desired. However, garbage collection has
advanced as rapidly as most computer-related technologies and is now a robust,
mature technology. Many object-oriented languages specify garbage
collection for all or part of their memory. Even C and C++ have at least one
commercially supported garbage collector that can transparently and
compatibly manage both new and existing programs. 
Garbage collected programs are usually as fast and responsive as
their manually managed brethren.  In fact, multi-media programmers
sometimes choose treadmill collectors  over hand-management because of its
superior real-time performance as manual management usually has difficulty
scheduling destructor calls smoothly. Of course, garbage collected programs
are generally more reliable and easier to develop, maintain, and reuse than
manually managed programs. Finally, garbage collection can be mixed with
manual management to provide the programmer with the broadest set of tools,
and garbage collection is much too important a tool to be absent from any
object-oriented programmer's toolbox.
 Paul R. Wilson, "Uniprocessor Garbage Collection Techniques", 1992
International Workshop on Memory Management, Springer-Verlag Lecture Notes in
Computer Science series.
 Geodesic Systems, Great Circle(TM) Automatic Memory Management System.
 Detlefs, Dosser, and Zorn, "Memory Allocation Costs in Large C and C++
 Henry Baker, "The Treadmill: Real-Time Garbage Collection without Motion