¿Hay alguna razón para usar ZoneId.of("UTC") en lugar de ZoneOffset.UTC ?

Conocemos la diferencia entre los dos como se indica en ¿Cuál es la diferencia entre ZoneOffset.UTC y ZoneId.of("UTC")? .

Versión <tl;dr>:

• ZoneOffset.UTC devuelve un mero ZoneOffset con ID "Z", desplazamiento de 0 y reglas de zona predeterminadas.
• ZoneId.of("UTC") devuelve un ZoneRegion con ID "UTC" y ZoneOffset.UTC incluidos.

</tl;dr>

Para esta pregunta, asumo el uso de UTC simplemente para facilitar el manejo de la fecha y la hora y no, porque algo podría estar ubicado en la región UTC o alguna otra razón comercial para tener esto como ZoneRegion real.

Por ejemplo, cuando se trata de ZonedDateTime . La única diferencia que pude encontrar fue que se imprime de manera diferente.

 2021-06-10T15:28:25.000000111Z 2021-06-10T15:28:25.000000111Z[UTC]

Estamos teniendo discusiones de revisión de código de un lado a otro sobre esto, así que supongo que este conflicto no es poco común.

Aquí están mis pensamientos hasta ahora

ZoneOffset.UTC

• Es una constante (y además, su valor de compensación (0) incluso se almacena en caché).
• Tiene (un poco) menos gastos generales, debido a la falta de información de la región.
• En UTC, no hay horarios de verano ni cambios históricos que considerar, como en cualquier otra zona horaria.
  Por lo tanto, un Desplazamiento de 0 es, en general, suficiente para todos los casos de uso que encontré hasta ahora (como convertir hacia y desde una Región de zona determinada con un estado de horario de verano particular).

ZoneId.of("UTC")

• En general, diría que se prefieren ZoneRegions a ZoneOffsets, debido a una variedad de datos adicionales específicos de la ubicación, como un horario de verano en particular o cambios de hora en el historial.
• Sin embargo, en el caso de UTC, ZoneId.of("UTC") es solo una región que se ajusta a ZoneOffset.UTC y no pude encontrar ningún beneficio hasta ahora. Hasta donde yo sé, en UTC no existen datos relevantes para la región aparte de las reglas heredadas de ZoneOffset.UTC .
• Necesita ser analizado cada vez.

Así que mi _conjetura_ es:

A menos que realmente necesite la zona/región horaria UTC por algún motivo (por ejemplo, de negocios), debería preferir ZoneOffset.UTC . Tiene una ventaja (menor) en su huella de rendimiento y la ZoneRegion UTC no parece proporcionar ningún beneficio que pueda ver o pensar.

Sin embargo, debido a la complejidad de la API de fecha y hora de Java, es difícil saber si me estoy perdiendo algo en esta discusión.
¿Hay alguna razón por la que alguien debería usar ZoneId.of("UTC") ?