The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.
If the offset becomes meaningless in the event of a rule change anyway, why save it when the most current rules will help you get the offset?
It is optional to store the UTC offset. The reason to store the UTC offset is to avoid ambiguity there might be when the timezone rules do not change.
If the timezone rules don't change and you happen to be storing a datetime that is during changing from DST to non-DST, you specify which specific time you are talking about. In autumn, clocks could be set back from 3:00 to 2:00. 2:30 happens twice. When you schedule the time you can ask the user "2:30 summer time or 2:30 winter time"?
So you only use the offset for anything in rare case there is an ambiguity (usually because of going off of DST), otherwise you just ignore it. In most cases even if the rules change like in the Chile example you would ignore it as well and use the offset provided by the timezone database.
There are problems when dealing with timezones and daylight saving changes but the example is just a case where the implementation was too naïve.