1) Do you think this thread is relevant to the design of control software for missiles?
2) A leap second is just an adjustment of absolute values. It doesn't really matter when measuring time using a stop watch.
3) A missile sent to hit a air or sea target don't care about what the wall clock says. It only cares about distances and relative times in a very tight control loop. An intercontinental ballistic missile sent to hit a city don't care if it is sent up 1 second later - it will just hit the target 1 second later.

You don't need to care about any drift unless you design an atomic clock. Why? Because the drift in the hardware forming the clock is many, many times greater than the leap seconds. So if time precision is important, the unit needs to synchronize using some other source. And that time reference will handle any leap seconds. If I set my clock from a time source, my clock will be correct within the precision I manage to set it, without the clock knowing that there have been leap seconds involved.

Have you still not realized that basically every single equipment you can see around you who works with time have zero or almost zero support for leap seconds? Very specific astronomical or other scientific equipment are the only equipment that really do need to understand the existence of these leap seconds.

Note that your example did not have anything to do with any leap seconds but with time drift. The clock didn't have enough precision to run for as little as 100 yours. Then consider what precision you need in a clock that should run for several years and still be exact enough that a one or two leap seconds still matters.

The GPS system drifts from UTC just because the airplanes do not want any leap seconds. They want to be able to take two absolute times and subtract and know the difference. And they know that they can't plan service intervals to reprogram the computers at least twice/year to teach the computers any new leap second that have been decided.

Your example with a missile computing postition etc does not care about leap seconds either. The missile gets an initial time synchronization when they spin up the electronics. After that, everything is operating in stopwatch mode. The missile failed the task because of clock drift - it needed more expensive hardware for the clock. Not support for leap seconds. A PC - or your wrist watch - needs more expensive hardware for the clock. Not support for leap seconds.

Have you actually thought about the implication of a leap second? A leap second means that a subtract of two timestamps 23:59:50 just before midnight and 00:00:10 directly after midnight will give the difference 20 seconds. But the actual time passed might be 20 or 21 seconds.

So a system that do make use of leap seconds can not subtract two times without taking into account the potential leap second at 23:59:60.

A system that do not use leap seconds will always report 20 seconds. And the actual time passed will always be 20 seconds give/take the tiny drift.

So in the end, 99.9xx of all equipment can ignore leap seconds because they don't matter in relation to percision of clock oscillators used.

And then you have a large set of equipment that have made the decision to explicitly ignore leap seconds and only work in relative time (stopwatch mode) because leap seconds incorrectly processed (one side not having received information about one leap second) gives huge fatal errors.

You finally have a very, very tiny fraction of equipment that must fully support leap seconds because they have clocks of suitable precision and also need to be able to measure events spanning years to super precision while still being able to interact with "normal" time.

In the end, almost all equipment in existence can manage by knowing that 60 is a valid second value, and that 0 is next value. And will get away with the errors of subtracting two time stamps without compensating for the number of leap seconds that have passed between the two times.

Now tell me exactly what products you work with that must take into account leap seconds (and then have an interface for refreshing the growing list of decided leap seconds) that make you think that embedded developers must handle leap seconds.

How does your WLAN router (let's assume you have one for this debate) fail if it doesn't support leap seconds? What is the worst failure if it supports NTP for time synchronization and decides to ignore an update that specifies the time 23:59:60? How will you, as end user be affected by the scheduled accessed that turns off your WLAN between 02:00 and 08:00 if your WLAN router didn't know about the june 30 leap second?