In short: on a lot of these devices it would be difficult or impossible to have a stable auto update mechanism. This could be due to flash size (16MB is considered large for consumer devices), or due to the state of the kernel modules responsible for hardware (e.g. wireless drivers).
Also there isn't usually a backup to the kernel in flash, so if your auto update is interrupted by a power failure or the user pulling the cord, you will have a bricked device. Good luck explaining the limitations of SPI EEPROM and compressed filesystems to a pissed off user with a brick. After the update you have to reboot, how do you schedule this on a device which is typically invisible to the user? In networks it's extremely difficult for these embedded devices to guess when someone might not be using it.
Having seen my fair share of ancient OpenWrt devices deployed in the field, the industry as a whole definitely needs to focus more on auto updates to resolve security issues.
However as the author points out, the sheer number of chipsets out there, it would be very difficult to accomplish without extensive testing.
I hope that we can all make meaningful progress toward auto updates of critical issues, but there is a long road ahead to that.