Every year when DST ends, there are two hours during which the locale name based time is not unique since it could be both shortly before or after the time got turned back.
But beside that this would make sense when everyone involoved is living in the same timezone, but when coordinating internationally (which tends to be the main focus when the ISO is involved) we really do not want such changes to happen automatically. Everyone in the local timezone is likely to be aware of time changes so they know they have to adapt, but everyone in another timezone might have almost no way of knowing. For them, an event starting at a different (UTC) time is a rescheduling, no matter if it is caused by some timezone adjustment or not. So hiding this behind some tzdb change instead of sending out new dates would most likely mean that they appear at the wrong time.
Also including offsets ensures that the person writing the time knows the right offset. In the last year, I had quite some meetings where the host wanted to be nice and send the time in the local timezone for every participant. Since only timezone names and no offsets were included and the host mostly assumed that their local DST rules apply globally, this resulted in a giant mess. Especially after people informed them about errors, so the times switched back and forth between times assuming DST or not assuming DST. Without seeing the offset, there was no way of knowing which time was actually intended. If a UTC offset is given, most local people can relatively easily verify that it is the expected offset but even more importantly, you can independently convert it to the right zone no matter what the author thought.
But beside that this would make sense when everyone involoved is living in the same timezone, but when coordinating internationally (which tends to be the main focus when the ISO is involved) we really do not want such changes to happen automatically. Everyone in the local timezone is likely to be aware of time changes so they know they have to adapt, but everyone in another timezone might have almost no way of knowing. For them, an event starting at a different (UTC) time is a rescheduling, no matter if it is caused by some timezone adjustment or not. So hiding this behind some tzdb change instead of sending out new dates would most likely mean that they appear at the wrong time.
Also including offsets ensures that the person writing the time knows the right offset. In the last year, I had quite some meetings where the host wanted to be nice and send the time in the local timezone for every participant. Since only timezone names and no offsets were included and the host mostly assumed that their local DST rules apply globally, this resulted in a giant mess. Especially after people informed them about errors, so the times switched back and forth between times assuming DST or not assuming DST. Without seeing the offset, there was no way of knowing which time was actually intended. If a UTC offset is given, most local people can relatively easily verify that it is the expected offset but even more importantly, you can independently convert it to the right zone no matter what the author thought.