I believe it comes from the very early days of computing, when memory was very limited, and it was not wise to pre-allocate a large chunk of memory for exclusive use by the stack. So, by allocating heap memory from address zero upwards, and stack memory from the end of the memory downwards, you could have both the heap and the stack share the same area of memory.
If you needed a bit more heap, you could be careful with your stack usage; if you needed more stack, you could try to free some heap memory. The result was, of course, mostly, spectacular crashes, as the stack would occasionally overwrite the heap and vice versa.
Back in those days there were no interwebz, so there was no issue of buffer overrun exploitations. (Or at least to the extent that the interwebz existed, it was all within high security facilities of the united states department of defense, so the possibility of malicious data did not need to be given much thought.)
After that, with most architectures it was all a matter of maintaining compatibility with previous versions of the same architecture. That's why upside-down stacks are still with us today.
Originally, the kill command could only kill a process, only later was kill enhanced to allow you to send any signal.
Since version 7 of Unix (1979) the default has been to signal the process in a way which can be caught and either handled gracefully or ignored (by sending a SIGTERM signal), but it can also be used to pull the rug out from under a process (a kill -9 sends a SIGKILL signal which cannot be caught and thus cannot be ignored).
Background
Computing, and Unix in particular, is rife with metaphor.
The main metaphor for processes is that of a living thing which is born, lives and dies.
In Unix all processes except init have parents, and any process which spawns other processes has children. Processes may become orphaned (if their parent dies) and can even become zombies, if they hang around after their death.
Thus, the kill command fits in with this metaphor.
Unix Archaeology
From the manual page from version 4 of Unix (the version where kill was introduced, along with ps) we find:
NAME
kill - do in an unwanted process
SYNOPSIS
kill processid ...
DESCRIPTION
Kills the specified processes.
The processid of each asynchronous process
started with `&' is reported by the shell.
Processid's can also be found by using ps (I).
The killed process must have
been started from the same typewriter
as the current user, unless
he is the superuser.
SEE ALSO
ps(I), sh(I)
I particularly like the final section of this man page:
BUGS
Clearly people should only be allowed to kill
processes owned by them, and having the same typewriter
is neither necessary nor sufficient.
By the time fifth edition had come around, the kill command had already been overloaded to allow any signal to be sent.
From the Unix Programmers Manual, Fifth Edition (p70):
If a signal number preceded by "-" is given
as an argument, that signal is sent instead of
kill (see signal (II)).
The default though was to send a signal 9, as signal 15 did not yet exist (see p150).
With version 6 the kill man page no longer mentioned the same typewriter bug.
It was only with version 7 of Unix that signal 15 was introduced (see see the signal(2) and kill(1) man pages for v7) and kill switched to that rather than using signal 9.
Best Answer
According to legend, the original stack received its name by analogy to the stacks of dishes in the university cafeteria: you put one on top, and the (spring-loaded) stack of dishes goes down a bit, you take one away and it pops up a bit. Therefore 'pushing' received a connotation of operating downwards, even though you don't actually push down on the plate - you just set it down and gravity does the work. "Pushdown stack" is still a common phrase, and stacks tend to grow downwards in memory (i.e. with decreasing memory addresses), although it is doubtful whether that has anything to do with dish stacks or not.