musl has completed the move with version 1.2, and embedded distros are moving to that.

glibc time64 support is still work in progress, as I wrote in the article

Many 32-bit embedded systems aren't able to update their libc.

Systems which can't update their libc or other system software have already broken in various ways. For example, in 2007 the Energy Policy Act of 2005 changed the date when DST begins and ends. Any system unable to update its libc data files since about 13-15 years ago will display the incorrect time. I have a cheap $10 radio clock which I've had for two decades. It always displays the wrong time for a few weeks around the DST change.

Any system which needs to display the correct time needs to have a mechanism for updates.

The time_t wraparound is a bit deeper and more serious, granted.

Displaying the time is not always needed; _tracking_ the time (storing it into a variable) is pretty much unavoidable.

Sure, but what percentage of those systems will be alive in 18 years? I'm sure it is non-zero, but it is also probably small. Regardless, those systems can't be updated, so they will have the problem either way. That says nothing about whether new systems should be given 64 bit time stamps.

Anything that is installed in a factory or say in a car repair shop might be alive in more than 18 years.

The place where my dad buys pool supplies still runs the entire business off an apple IIe