In my experience "this timestamp is UTC, show it to the user in whatever timezone they might be in" is the most common case for times in an API/file format, so giving it the Z shorthand makes sense to me.
While when using an explicit time offset, `+00:00` doesn't appear particularly special or more common than other offsets, so I don't think a shorthand for this case is useful.
Other than instants in time and durations, other expressions of time information tend to be a bit more "wibbly wobbly, timey wimey". For instance, I might specify the week of the year without any more precision.
Another example is that a date can't be converted to a range of instants in times (the first and last second within the day) without knowledge of where it is observed. Games for instance will measure this at some business-decided timezone (say UTC or the timezone of their first server), because having events time out at different times for different people is much more complex.
So when representing an instant in time, a UTC shortcut is easier - if people agree that times are shared with a Z offset, then you simplify parsing. However. there are reasons people would also want a fully specified point in time that preserves a timezone offset as well.
While when using an explicit time offset, `+00:00` doesn't appear particularly special or more common than other offsets, so I don't think a shorthand for this case is useful.