Maybe this is just my bias as a low-level MCU programmer, but I wonder if this isn't a definition problem more than anything else. To my mind, if your code has problems like this:
> We notice the old devices piling up in a desk drawer, hardware perfectly fine but with ancient firmware that just won't play with modern services.
Then it's not firmware, it's full-fledged software, and ought to be treated as such. Calling a smartphone OS "firmware" is particularly odd to me -- it runs on a general-purposes computer! It takes up gigabytes of storage space! It updates itself over an internet connection that it also manages! -- and I think it gives the wrong idea about the system it's installed on and the nature of the software itself. In particular, anything that needs regular updates is not "firm" in any sense.
It is hard to draw a firm line somewhere between the code in a tiny microcontroller running a battery charger and the operating system running on a general-purpose application processor. Motherboard BIOSes are a bit of a marginal case. But I think there is a useful distinction between "acts like part of the hardware and never needs to be changed" vs. "is the core of the product and when it stops being updated the product quickly becomes useless". Very few people are clamoring to hack on the firmware for their PC's power supply or their car's air conditioner.