There are several examples I've seen of firmware on devices failing because of bit rot, so that's not true. We used to design devices so that the bootloader was pulled from NOR instead of NAND because of this. Then the device could be recovered using a USB stick.
Most people don't encounter it because their device was updated at least once. People should be less trusting in flash drives than they are, I recently pulled three USB flash sticks out of storage and two of the three are now unhappy.
There's a strong argument that consumer electronics should be able to be more incrementally upgraded. Including things like baseline upgrades for certificates. One of the things about TVs and these systems is that they are usually running on something like OverlayFS to avoid corruption of the base OS and enhancing security/integrity. They focus on replacing the underlying image, which is often security signed as well. If you screw something up with a device that's in a customers home then you're going to be spending a lot of money fixing it, the manufacturers have their war stories in this regard, so they're very risk adverse.
As for freezing the backend, you can't. Your API will evolve and for example if your database changes then your backend services will need to be touched. That database will change, some metadata or label will need to change. Even if you keep the API the same you'll need to maintain the legacy backend. Then you need that service running, consuming compute, for years even if there's hardly anyone using it and it's costing money. Then you need security patches for the backend service because the framework needs upgrading or the OS needs upgrading. Eventually the backend framework will be EoL/EoS and so you need to spend to upgrade. It's like saying we'll keep a Java backend running on a public facing API well beyond it's life, log4j anyone?