People are good at creative thinking and bad at bookkeeping. Computers are bad at creative thinking and good at bookkepping. Automatic memory management frees programmers from having to do the bookkeeping for "what bits are where" during program execution and lets them concentrate instead on more creative tasks.
Very early computers forced programmers to code their own arithmetic operations, assigning specific bits to specific register and other locations. Assembly langage programmers have to code their own function call mechanisms and variable storage, carefully keeping track of where things are in memory. PC programmers sometimes had to manage paging between different memory areas or to disk, due to a lack of automated virtual memory management by the operating system.
Automatic memory management for computer languages takes the next logical step. As far as the programmer is concerned, each piece of data created during execution of the program is always available. (This is called having indefinite extent.) If the program needs to use that data again later, it is still available. In reality, resources are limited, and the computer keeps the data available only as long as it can be proved that the data might still be used. When the data can be shown to no longer be needed, it is considered garbage. The process of reclaiming the space used by uneeded data is called garbage collection.
The computer keeps track of where the data is, so that the programmer does not have to. In fact, in some systems, the garbage collector actually moves the data around within different memory systems of the computer so that the most often used data is available most quickly.
Without automated memory management, a programmer must keep track of whether or not data is stored in a kind of memory which may be overwritten (eg. the stack or registers). If so, the programmer must take care that the data is not used after it has been overwritten. If the data is in a more permanent memory area, the programmer must make certain to "delete" the object after the program is finished with it, or memory will quickly become exhausted. There is no way to explicitly delete data on the stack when they are no longer needed. Failure to clean up memory that is no longer being used is called a memory leak. Accessing memory which has been mistakenly deleted or otherwise overwritten results in errors that are exteremely difficult to track down. It is even more difficult to avoid these errors in large projects involving multiple programmers unless automatic memory management is used.
Although not strictly a garbage collection issue, most garbage collected languages, including Lisp, do not use pointers within programs, but provide arrays and other "holder" utilities as first class objects. This eliminates another major source of bugs.
Early garbage collectors operated only when usage of physical memory had reached certain limits, at which point the program stopped while the system examined all allocated memory. This caused annoying delays. Modern garbage collectors operate a little bit at a time - examining a little bit of memory each time memory is allocated or even during pauses while the system waits for user input, slow disk drives, etc. Most of the time, the activity of the garbage collector is not noticed. There are also real-time garbage collectors which guarantee that any potential delay will not be longer than a specified small amount.
For all programs, then, automated memory management makes programs safer and gets them developed more quickly. For very large programs, it can be so difficult to keep track of memory, that even if the program can be made to work without automated memory management, it is not likely that the result will be faster than with a modern garbage collector.
For more information on automated memory management, see: