The short of it is that using UTC for events in the past is usually OK (you can at any moment recalculate the wall clock time in the past with UTC plus location data), but not for future events (e.g. scheduling, opening hours). Because the intent of stored future datetimes is almost always the wall clock time in the location where the event takes place. If TZ rules change for that location the intent is to pin the event to the local time rather than to UTC. For disambiguation, future events should ideally include location as well as datetime, though this is often omitted / implicit.

The remaining edge cases are future events that span different time zones (e.g. scheduled calls with participants from different TZs). If one of the timezone rules chances, this can only really be resolved by rescheduling and updating the info for the participants.