In some instances, and I can fathom just a few - mostly in regards to 32-bit time-stamp bugs, end of life is acceptable; this product should no longer be in service. Given enough time, a bug of convenience will throw the entire system out of whack. Said bugs of convenience are put in place by developers who cannot fathom the system being in use after the year 2106 (or 2038) or the entire flash memory module will fill up or the EEPROM will finally see 100,001 write operations.
But in others, I'm finding it hard to justify. There are many industries where "it's worked for years and we're not going to change it" is the modus operandi. In manufacturing operations, like a paper mill I worked in, many times the individual embedded systems don't have to be complicated; they have one job and they just have to do it right. In fact, they'll often employ the same out-dated desktop and servers on isolated networks for over 15 years simply because it's still working and there's no pressing need to change.
So, in some instances yes, sure, let's give the poor chips a dignified rest. But I'd really rather not find out that a when the warranty on a pace-maker goes ou...
(User expired during the writing of this post.)