Why doesn't Ctrl-C kill the Terminal itself?

Ctrl+C is the interrupt signal. When you type this in a terminal, bash sends SIGINT to the job in the foreground. If there is no job (which is the case when you've just opened a terminal), nothing happens. The terminal emulator program is not a job running in the shell, so, it doesn't get the signal and doesn't close.

If you want to close the terminal with a control key, use Ctrl+D (EOF) which causes bash to exit (and closes the terminal too).

_{See also: Bash Beginner's Guide on signals and in more depth How signal handling works
note: this answer has been edited since comments were posted}

The ^C keystroke, like other keystrokes*, isn't magic--it sends a keycode to whichever program has focus. (In X, the keycode is 54 for the C with a modifier of 0x4 for Ctrl.) The program that's receiving the stream of keys is responsible for doing something appropriate with them--remember that in many GUI applications, the keystroke copies to the clipboard.

When a GUI terminal emulator (e.g., Konsole) or a virtual terminal receives a keystroke that it interprets as ^C, it can do one of three things. If the terminal is in raw mode, then the running program has asked the terminal not to perform any handling of special keys itself and to pass them straight to the program. Some programs that support advanced features like line editing receive keyboard input in some configuration in between complete raw keystrokes and processed lines of text; bash, for example, receives keystrokes one at a time. ^C is interpreted by the terminal, but the backspace key is sent to the shell as-is.

Most programs, however, use cooked mode (because it isn't raw), where the terminal interprets some basic keystrokes before actually sending them to the program (this is why you can use backspace in cat). In this mode, the terminal itself translates the ^C keystroke into a SIGINT signal and sends it to the child process. Since the terminal generated the signal, it will not get confused and terminate.

• SysRq really is magic.

^C is usually mapped (see stty -a) to the SIGINT signal (see man 7 signal).

An un-caught SIGINT interrupts the running process, BUT...

SIGINT is one of the signals that a process can specify behaviour for ("Catching a signal").

What you call "the terminal" catches SIGINT, and goes back to work.