Here one current example: I schedule in August 2020 a meeting, targeted for Fuji, for 2020-11-11 and send an .ics invitation, bundling tz definitions. Afterwards the Fuji experts change DST rules, so that the switch does not happen on 2020-11-08 but on 2020-12-20. The UTC offset calculations, included in the .ics invitation, are therefore for that meeting wrong. Nobody thinks on regenerating and resending the .ics file with new tz data. If the OS gets updates, then that event might be presented correctly, if the .ics interpreter ignores the bundled TZ definitions, if the .ics interpreter sees no bundled timezone definitions, or if the .ics interpreter shows to the user, that the bundled TZ definitions are outdated, and there are two possible times for the start.
There is no ultimate right way on technical level to prevent troubles here, not bundling the time zone definitions in the .ics file saves band width.
See also https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/fiji-dst-end-date-correction-update-now-available/ba-p/1669658 and https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interim-guidance-on-2020-time-zone-updates-for-fiji/ba-p/1766806 .