My impression was that autoupdate was not the default because the devices it runs on only have so many resources, and there's a non-trivial chance of bricking the device (given how many devices are supported)? It's not like other vendors are doing any better in this space (and I've seen enough things in the "IoT/embedded" space brick themselves with updates to be a bit wary of autoupdates).

Auto-update is also a bad idea unless you can make it really secure, which is hard to do on devices so constrained they don't even have a clock to keep track of what day it is to judge whether a certificate is still valid.

Minimizing the chance of bricking the device with an automatic update requires at a minimum having two copies of the OS, so that the running copy isn't trying to modify itself and can remain as a fallback in case of a broken update. That's not too challenging these days now that most routers are using NAND flash, but for a long time it was common to use very small NOR flash modules with the absolute minimum capacity.

Updates don’t currently have a way to ensure that user installed packages have their configurations updated appropriately, so user installed packages may break on update. Additionally, as a sibling comment pointed out, official images don’t include user packages, so you’d either need a scalable way to build custom images or the updater would need to be smart enough to reinstall packages after update.

It would still be nice to have an official automatic update feature that is opt-in for stock systems.

You also need to rebuild the firmware with the installed packages. Otherwise you end up without your packages installed. That requires a server to build the firmware for your device. Doing this automatically for everyone is resource intensive.