Add a button to LuCI to upgrade(apk upgrade) all packages.
This would be an exceedingly bad idea and likely won't be implemented.
Upgrading packages (via the CLI opkg upgrade/apk upgrade commands or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.
The way that this can be done safely is not by using a mass-package-upgrade button, but rather using OpenWrt Upgrade Tool (OWUT) / Attended Sysupgrade (ASU) which will generate an image that includes all of your packages and it will 'capture' upgrades to packages that may have happened since the packages were last installed.
A warning can be made. The user can also update all packages individually and break the system.
Or better yet, don't create options that are known to be damaging.
Multimillion-dollar corporations are not afraid to release even buggy updates 
Also OpenWRT is firmware not for people who don't know what they're doing.
I cannot count the number of people who have broken their installations as a result of running a script that bulk updates packages. That's why the warning was written.
With OWUT, there is an easy and fast alternative that is actually safe.
The other thing to note is that attempting such bulk upgrades is only suitable for systems with very very large storage (measured in hundreds of megabytes or larger) because on smaller (i.e. embedded/all-in-one) devices it will rapidly fill up the flash storage and fail as a result of a memory full condition (assuming that an ABI failure doesn't happen first).
That said, you are welcome to use the scripts that have been used in the past (and typically broken the users' systems). Don't say you haven't been warned.
Many, many common routers have something like 1-20 MB of usable := free available space[*] (for the overlay). Even if the packaging, bootloader, and dependency stuff would be 101% spot on, you would end up with 0 bytes free (and very 'interesting' side effects/ complete breakage) very quickly.
--
[*] 128 MB NAND does not equal >100 MB usable space, you generally have dual-firmware setups, for halve your flash from the get-go - then you have to remain within the constraints set by the OEM partitioning. Very few routers give you more than ~32-40 MB space usable as such, minus the ~8 MB OpenWrt needs for a basic image. rinse and repeat. In practice, it's smaller than you may think.
Install all packages, what the genius idea 
Just clear the cache after updating packages.
Add protection to the APK so that it stops the process when there is little space/operational memory left.
Also, a warning and an additional warning if the router does not have the latest version of OpenWRT before updating the packages.
So 6 Feature Requests total?
Regarding adding a warning about the "latest version" - are you asking for this in 25.12.x, or a future version?
The problem is not the package manager (not-) checking the available space (which is kind of tricky, e.g. jffs2 uses -bad- online compression), it's hitting the wall within very, very few upgrade cycles on most devices. It's not a case of the package manager acting gracefully (which is a tad difficult considering apk's approach of changing state and then fixing the world), it's a topic a severely limited overlay space for your shenanigans.
…and I've not even touched the real topics (soname concurrency, symbol versioning, base rootfs vs overlay ABIs, bootloader constraints, kernel concurrency, etc.) here. Restricting the argument to a very simple topic (very limited storage) that should be easy to understand.
As far as I know, when OpenWRT is launched, it loads binaries from userspace (except for the kernel, of course). And to avoid ABI conflicts, I have already written about checking the latest version of OpenWRT before updating.
You haven't understood the boot chain and how the overlay, the bootloader or the package manager (within the specific context of OpenWrt on embedded devices with flash storage) work, it's more complicated than you think. No, I can't start with the birds and the bees here either, as an open-ended breakdown suitable for all audiences would amount to a small 5 lbs paperback novel.
There are reasons why OpenWrt is the way it is, that's unavoidable for the (vast majority of) devices it is targeting, devices with 8-40 MB storage on average, very restricted bootloaders and flashing constraints, which generally are NOT easily recoverable (where insert boot floppy into drive a: is not an option). Unless you want to change the minimum target for OpenWrt to x86_64 or ARM SBC with gigabytes of main storage (>>1 GB), multi-core in the GHz of performance, RAM in abundance (>>512 MB), with a clear recovery option (bootable from removable media, UEFI/ grub-like upgradeable bootloaders) and magically increase the developer count by at least a factor of 10-15, that's not going to change - and such a change would be mutually exclusive with the devices it is running on today. Yes, apk -within an alpine linux ecosystem- can do more than OpenWrt can/ will ever be able to provide.
So what's the point of OpenWrt then, you might ask - until you try to install a full-fledged general purpose linux distribution (and be that alpine) on your 20 buck plastic router, barely meeting minimum system requirements. It's a question of priorities/ target audiences and tradeoffs.
Breed (Breed Web Recovery) / U-Boot (U-Boot Web Recovery / TFTP Failsafe) / CFE
(CFE MiniWeb Server / TFTP Recovery) / RedBoot (RedBoot Console / TFTP Recovery)
/ RouterBOOT (Netinstall) / ROMMON (ROMMON Mode / tftpdnld) / ADAM2 (ADAM2 FTP)
/ PSPBoot (PSPBoot FTP / TFTP) / EVA (EVA FTP / AVM Recovery Tool) / Barebox
(Barebox Console / barebox_update)
This is much faster and easier than inserting a USB flash drive, selecting the installation device, then clicking on the desired partition, and so on.
Cool story, why don't you put your hypothesis to the test then?
Quietly, please.
This already exist:
As indicated earlier, it is extremely bad idea to update individual packages.
Much better is to request a new image.
New image builds are updating all packages.
What should I test?