That way you can merge them from different sources and sort them to help figure out interactions and causality. There might be clock drift from different sources but that's a much smaller problem than trying to eyeball multiple different logs concurrently, or write ad-hoc scripts to enable merging.
When people try to apply this to other time related info, it's always a disaster.
If you can’t go that far and still need local time zones in some specific part, just embrace your fate and keep and display timezones everywhere, even when it’s UTC.
TBH, I’ve never seen an organization that could 100% move everything to UTC. Especially with countries following DST and other shenanigans, and you want to quickly be able to compare events at the same local time.
If you're going to do it in storage, keep it outside the ISO/8601 string. Chronology is the most important thing to get right. Locality comes after
Unless the whole world agrees to communicate times in UTC, at some point, you will share a screenshot or a log message with someone outside of your company, and they cannot assume what time zone it's in.
What are you doing in this case?(in case you worked with database logs), export to csv and then do it with unix tools?
For one: those standard Unix tools can convert from date/time values to timestamps just as easy. Arguably easier.
And a timestamp is merely an Int, so many languages, databases, APIs and so on, lack ergonomic methods to convert timestamps to datetimes. But have easy ways to do the reverse. It's almost always easier to convert dates, times or datetimes to timestamp ints (or floats) than to convert an int or float to a date, datetime or time.
A timestamp.toString() is unfamiliar to humans, a datetime.toString() is not. The list of small benefits in favor of actual date or time types just goes on.