The context was specifically the handling of times that don’t include an offset (or perhaps time zone, it was unclear). The correct answer there is not UTC (which is flatly incorrect, depending on a locally-enforced convention that incidentally deviates from the most common meaning of such time stamps), but rather “don’t enter that situation in the first place, because any other answer is wrong”.
—⁂—
For the rest of your statement: for times not tied to a particular location or time offset, you should always use UTC in the form of the offset Z, in ISO 8601/RFC 3339 terms, since specifying any other offset indicates that it means something. (Note that RFC 3339 tried to have -00:00 be the neutral offset and Z and +00:00 meaningful, but that is acknowledged to have failed, and so https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... is updating it to match actual usage.) But for things that involve humans and are anchored to a particular time zone, using UTC and not storing a time zone is wrong: you should store the relevant time zone and (fallback) offset so that if the time zone definition changes (as they do, sometimes with less than a few days’ notice), future times can be corrected, which they can’t be if you anchored them to UTC. So: things like system logs, use UTC; online conferences, use UTC; location-bound conferences, use that location’s time zone; general user calendars, use the user’s time zone; calendars for companies that straddle time zones (or people that work across time zones): deliberately choose a time zone or offset to anchor things to (sometimes at the level of individual events), especially for the sake of recurring event periods if you use a time zone with DST.
—⁂—
For the rest of your statement: for times not tied to a particular location or time offset, you should always use UTC in the form of the offset Z, in ISO 8601/RFC 3339 terms, since specifying any other offset indicates that it means something. (Note that RFC 3339 tried to have -00:00 be the neutral offset and Z and +00:00 meaningful, but that is acknowledged to have failed, and so https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... is updating it to match actual usage.) But for things that involve humans and are anchored to a particular time zone, using UTC and not storing a time zone is wrong: you should store the relevant time zone and (fallback) offset so that if the time zone definition changes (as they do, sometimes with less than a few days’ notice), future times can be corrected, which they can’t be if you anchored them to UTC. So: things like system logs, use UTC; online conferences, use UTC; location-bound conferences, use that location’s time zone; general user calendars, use the user’s time zone; calendars for companies that straddle time zones (or people that work across time zones): deliberately choose a time zone or offset to anchor things to (sometimes at the level of individual events), especially for the sake of recurring event periods if you use a time zone with DST.