This is mostly a holdover from when WordPress supported PHP 4.
PHP 4 didn't have a way to set timezones like that, and so do timezone related calculations. In order to work around this, WordPress implemented its own time calculation code.
Originally, the timezone setting was limited to selecting +1 hours, +2 hours, etc. It was annoying and you had to change it twice a year for daylight savings time.
So 4 years ago, around WordPress 2.8 or so, I wrote the patch that added the new method of choosing timezone. If PHP 5 was on the server, it would get the timezone information from PHP and then apply the calculations automatically to handle daylight savings. This is where the timezone_string came from.
However, because PHP 4 was still being supported, the old code for calculating timezone was retained, and to make all WordPress instances behave identically, the default timezone was set to UTC. My first patch actually did set the date_default correctly, but this caused strange and inconsistent behavior because much of the core assumed UTC for date() calls and the like.
This may be fixed in the future, but it's a big job. Lots of code to deal with and adjust to the new way of doing things. It's not a priority though, because it works for now. However, it is a bit of a minor performance hit (see http://core.trac.wordpress.org/ticket/23132), so that might affect things.
Note that you should not call date_default_timezone_set to change the timezone, because much of the core still assumes UTC when doing calculations. This can affect things like scheduling of posts and cause other strange behavior.
Instead, you should use the functions in WordPress to retrieve times, such as current_time, for example. Alternatively, if you do change the date default, make sure to change it back to what it was before after you're done.