Maybe if you want to schedule a meeting for 4pm local time, no matter the time zone. Some countries have very unpredictable daylight saving schedules.

(For example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551195 - "To keep on with the great work our government has done the past two years of deciding stuff with 2 or 3 days of anticipation, the government has just decided that we won't switch to DST this Sunday.")

Vehicle reservation system. If you book a car at 10am, it can't suddenly become 11am because dst changes. There are a bunch of use cases (e.g. financial processing) which require that you map that to utc.

Most things that happen in the 'real world' happen at the same local time regardless of government meddling with timezones. Microsoft had a really hard time fixing everyone's meeting times the other year, when the US decided to move the DST switchover date by a few weeks; if Exchange had stored symbolic timezones rather than numeric then nothing need have changed.

If something's scheduled for the future, either it should be scheduled absolutely (with direct reference to UTC) or with reference to its location (with a symbolic timezone). Numerical timezones are dangerous, because they look like they provide enough information but they don't.

Incidentally, please use Olson-style location-based TZ symbols, rather than three-letter zone names. The three-letter names aren't nearly as helpful when resolving DST changes.

Recurring events. Specific points in time are just that and can be represented properly, but what about that 10am meeting that happens every 2 weeks that you added into your calendar? The calendar app doesn't go create an infinite number of events into the future when you add the recurring event -- it simply stores 10:00 America/New_York and does the proper timezone conversion when for each discrete date.