The chips themselves add a bunch of new failure states to consider beyond software bugs, too. Maybe a bad wire or component puts too much load on the microcontroller's wee internal pin drivers and they melt into a permanent "on" state. Or a voltage fluctuation browns out the chip on boot, partially randomizing its RAM or registers. Or the chip manufacturer fixes some errata or discontinues a particular part number and now a pin you've left floating has become a hardware heisenbug. Or the wrong bit flips in your EEPROM after being in a hot machine for a few years. Suddenly a boring 555 looks pretty good. (Keep in mind, we're talking about "turn off heater after pulses stop", not "abort launch sequence if tank 3 pressure low". The latter is way above my pay grade.)
For every task you could also use a 555 timer for (with dedicated analog support complexity,) you are talking about tens of lines of user code at most.
Even if you had to do everything directly with registers, the amount of C or Rust here is minuscule.
The chips themselves add a bunch of new failure states to consider beyond software bugs, too. Maybe a bad wire or component puts too much load on the microcontroller's wee internal pin drivers and they melt into a permanent "on" state. Or a voltage fluctuation browns out the chip on boot, partially randomizing its RAM or registers. Or the chip manufacturer fixes some errata or discontinues a particular part number and now a pin you've left floating has become a hardware heisenbug. Or the wrong bit flips in your EEPROM after being in a hot machine for a few years. Suddenly a boring 555 looks pretty good. (Keep in mind, we're talking about "turn off heater after pulses stop", not "abort launch sequence if tank 3 pressure low". The latter is way above my pay grade.)