It's a hassle for anybody doing or recording "physics" as they cannot log against UTC (which may or may not have an added second or removed second in some interval if it happens to overlap the adjustment zone).
Those things that really do rely on actual "elapsed time" rather than the difference between two recorded "book times".
Does this happen? Yes, a few times in my career in geophysical exploration - it's why multiple bits of gear are synced to a reference "real clock" which gets logged against the raw GPS epoch time (real time since Sunday last week(?)) and processed "UTC" time (some variation of it).
The most annoying part is that a lot of GPS gear automatically "corrects" to UTC without giving clear indication of it. Things would'be been fine if the standard was to explicitly sent out TAI timestamps, with a leap second offset for the people who insist on UTC.
Well, yeah, that to - although TBH it's never been an issue in my line of work which started with (LORAN actually, and then moved to..) off book reverse engineering of the OG NavStar format. To this day it's still "raw" GPS packets that are logged - and later post processed for greater accuracy (and often blended with a local area fixed position base stations "corrections" for GPS fix wobble).
There's a lot of fiddly pedantic stuff that goes with scientific data recording, timekeeping is but one domain of possible issues.