At first thought, it probably seems odd that the stack “grows” downward.
The reason it expands downward is a consequence of GCC compiler commonality with other PC architectures. The AVR µC data memory is proportioned in a similar fashion to these other processors. Global data (program variables) is allocated starting from the bottom of memory. While this data is static and know at compile time, it uses a fixed-portion of the lower memory. At the end of this memory segment (a combination of both the data and bss sections), is the area called the “heap”.
The heap is used for “dynamic” memory allocation. Dynamic memory is that which is acquired and released while the program is running, usually through the use of the malloc()/free() functions or the C++ new/delete keywords. Therefore, this area is subject to expansion and contraction during program execution. Since the compiler cannot know the amount of dynamic memory the program might use, it is up to the programmer to keep track and manage this memory.
The heap obviously expands upward, towards the stack. One of the many potential problems with dynamic memory arises when its allocation impinges upon the downward growth of the stack. If dynamic memory overwrites the stack, the consequences are almost always fatal.
However, to complete the story, since the heap grows upward, the stack was left to, and must grow downward. If nothing else here, you should have gleaned that dynamic memory and ignorant use of stack resources are not issues to be taken lightly in embedded programming.
Further AVR uC stack information is located here.