Secure Boot on other platforms is all-or-nothing, but Apple recognizes that Mac users should have the freedom to choose exactly how much to peel back the security, and should never be forced to give up more than they need to. So for that reason, it's possible to have a trusted macOS installation next to a less-trusted installation of something else, such as Asahi Linux.
Contrast this with others like Microsoft who believe all platforms should be either fully trusted or fully unsupported. Google takes this approach with Android as well. You're either fully locked in, or fully on your own.
I'm not sure what you mean by that. You can trivially root a Pixel factory image. And if you're talking about how they will punish you for that by removing certain features: Apple does that too (but to a lesser extent).
https://github.com/cormiertyshawn895/RecordingIndicatorUtili...
On many Android devices, unlocking the boot loader at any point will also permanently erase the DRM keys, so you will never again be able to watch high resolution Netflix (or any other app that uses Widevine), even if you relocked the bootloader and your OS passed verified boot checks.
On a Mac, you don't need to "unlock the bootloader" to do anything. Trust is managed per operating system. As long as you initially can properly authenticate through physical presence, you totally can install additional operating systems with lower levels of trust and their existence won't prevent you from booting back into the trusted install and using protected experiences such as Apple Pay. Sure, if you want to modify that trusted install, and you downgrade its security level to implement this, then those trusted experiences will stop working (such as Apple Pay, iPhone Mirroring, and 4K Netflix in Safari, for instance), but you won't be rejected by entire swathes of the third-party app ecosystem and you also won't lose the ability to install a huge fraction of Mac apps (although iOS and iPadOS apps will stop working). You also won't necessarily be prevented from turning the security back up once you're done messing around, and gaining every one of those experiences back.
So sure, you can totally boil it down to "Apple still punishes you, only a bit less", but not only do they not even punish your entire machine the way Microsoft and Google do, but they even only punish the individual operating system that has the reduced security, don't punish it as much as Microsoft and Google do, and don't permanently lock things out just because the security has ever been reduced in the past.
Do keep in mind though, the comparison to Android is a bit unfair anyway because Apple's equivalent to the Android ecosystem is (roughly; excluding TV and whatever for brevity) iPhone and iPad, and those devices have never and almost certainly will never offer anything close to a bootloader unlock. I just had used it as an example of the all or nothing approach. Obviously Apple's iDevice ecosystem doesn't allow user tampering at all, not even with trusted experiences excluded.
Fun fact though: The Password category in System Settings will disappear over iPhone Mirroring to prevent the password from being changed remotely. Pretty cool.
Its reasonable to install a different OS on Android, even if some features don't work. I've done this, my friends and family have done this, I've seen it IRL.
I've never seen anyone do this on iPhone in my entire life.
But I flipped and I'm a Google hater. Expensive phones and no aux port. At least I can get cheap androids still.
My comment's about macOS. Even though it's a completely different market segment than Android, I'm only using Android as an example.
I used to tweak/mod Android and most recently preferred customizing the OEM install over forks. I stopped doing that when TWRP ran something as OpenRecoveryScript and immediately wiped the phone without giving me any opportunity to cancel. My most recent Android phone I never bothered to root. I may never mod Android again.
Alternatively, read about iBoot. Haha, just kidding! There is no documentation for iBoot, unlike there is for uBoot and Clover and OpenCore and SimpleBoot and Freeloader and systemd-boot. You're just expected to... know. Yunno?
For power management, you can however give some credit to ACPI, which is not directly related to UEFI (it predates it), but is likewise an open standard, and is generally found on the same devices as UEFI (i.e. PCs and ARM servers). ACPI also provides the initial gateway to PCIe, another open standard; so if you have a discrete video card then you can theoretically access it without chipset-specific drivers (but of course you still need a driver for the card itself).
But for onboard video, and I believe a good chunk of power management as well, the credit goes to drivers written for Linux by the hardware vendors.