I think if we all stipulate that some form of "display UTC" is the only representation that should be stored or forwarded,
You expect high-volume logging tools and network servers to convert every timestamp to year-month-day-hour-minute-second-subsecond?
I only expect entities that wish to exchange timestamps with other entities to convert them to a "display UTC" equivalent representation, which does not imply such a full breakdown. It is up to the protocol designer to choose the "display UTC" representation, and it is up to the local system to choose the timestamp representation. Both parties will undoubtedly want to make choices that simplify any conversions. [It would also be possible for the protocol to negotiate a mutually acceptable representation to avoid any conversions, but everyone should accept the "display UTC" equivalent.]
What exactly is the benefit of these conversions?
The benefit is the separation of local and remote representations. Might I liken it to exchanging floating point values?
you're kidding yourself if you expect UNIX filesystems to start storing inode times in that format.
I only expect them to store something equivalent to "display UTC". [POSIX time_t's fail to represent leap seconds. People seem to dislike struct xtime because of the ability to represent bogus leap seconds. TAI requires a leap-second table.] So choose any flavour you like locally, but don't force that choice upon those you communicate with. And recognize your shortcomings (for example, POSIX-time_t based file systems screw up file time orderings during leap seconds).