I will never again complain about servers being set to timezones outside UTC and what a pain in the ass that usually ends up being.
If it's a timezone that has its operational properties change, you have the potential for confusion where there is disagrement about when a given time happened or will happen; think about how fun it is when daylight savings rules change. Sometimes, although not really that often, a time zone's offset is simply changed; hopefully with warning, but maybe not.
If the timezone has daylight savings, you get to deal with all the fun of most days having 24 hours, but some having more or less.
If the organization moves to a new time zone, either because it physically moves or because the locality its in changes time zones for whatever reason, now you have a problem; it's not fun to deal with multiple time zones in server infrastructure, but now you have to pick if you want to move all the servers, move only some servers, or have your servers in a different time zone than your org. If the last option was fine, you might as well use a sensible timezone to begin with.
2. Daylight savings mean that events an hour apart can end up having the same timestamp.
I've fortunately never experienced (1), but for (2), it helps to print the offset to UTC everywhere timestamps are printed, even for UTC. (I basically never trust an "unzoned" timestamp.)
Customers, partners, stakeholders all think in terms of local time zones, as do I; some amount of conversion is inevitable.
Ultimately, local time is a presentation layer concept, so why shouldn't I configure that presentation layer so that I have to do one less conversion in the most common case (of figuring out when something happened relative to my wristwatch or that of most of my customers)?
Here's something you may not be thinking about - your presentation layer may save a configuration step, but now every system that interacts with your server (who have all likely defaulted to UTC) have to know about this now. Think - logging infrastructure, schedulers, cloud infra, etc. So now you have to configure all those as well. Anything that touches the host will need to be reconfigured to save one very minor and commonly done thing on the presentation layer. Really doesn't make sense, as an infra guy.
No, why? Almost all APIs/interfaces use zoned timestamps or seconds since the Unix epoch.
The argument of “servers must run in UTC” sounds a bit like “servers must run with an English locale” to me in that sense, as if the locale changed the name of API parameters or enum values instead of just human-readable strings.
See: Google