The battery-conserving mechanisms of Android are not particularly hardware-specific on most devices.
Ideally, Android (or their patched version of the Linux kernel) would expose an API for each different kind of device. An general API for cameras, an API for audio, etc. The manufacturers would then write device drivers that implement / fulfill the functionality of these open/generic APIs. (This is how things are done on PCs.)
Some phones have two CPUs or SoCs, one being energy-efficient and the other highly-performant, and the system switches between them based on the workload. But an update of the OS could simply add & expose an additional new API for dual-SoC systems.
Decoupling device drivers and OS releases would be a huge win for everyone. We'd get the security update swith newer OSes, and even driver updates would be simpler.
PC peripheral manufacturers often release updates to their device drivers, and for a Linux and Windows users its relatively straightforward to update a device driver. E.g., I just updated my Nvidia graphics driver on Linux to the latest version two days ago. I have several kernel modules installed, and apt-get handled everything seamlessly, and built a new kernel image in a jiffy.
How often do you see device drivers updated on Android? Especially if there's a bug, how long before it's fixed? All of the drivers on Android are baked into this giant system image, and the system image contains so many disparate components, that shouldn't all be locked together. The Android system image release process is so broken. The Google -> Manufacturer -> Carrier approval & release is slow and dysfunctional.
The best way to go would be to adopt standard Linux distro practices, use a good package manager (like NixOS) that'll manage and assemble all the disparate system components, instead of shipping one giant frozen-in-time system image.