The idea is to have the server safely shutdown BEFORE it loses power, so that BIOS setting wouldn't mean anything. The server does not loose power while it it running, so it will never "restore last state after AC loss". The idea is that you can run a low power device (the raspberry pi) for which you don't care if power is cut abruptly and that can talk to both the UPS and the wake-on-lan of the server directly over ethernet. It being local means those WOL are much more likely to work than trying to send them from outside your network when you're remote. It's a lot simpler to set this up once than it is to recover a server with a corrupted file system due to power loss or lose access to your server for weeks because a thunderstorm knocked out power for 30min at the beginning of a long trip. That pi can also take care of other always on services like a pi-hole, home assistant, etc.

I can dig it...but surely the simple option is to have the PC wake up on power restoration, right?

After the PC shuts down, the UPS runtime will increase by a lot. So the power might come back before the UPS turns off, so as far as the PC can see, the power was never lost.

Edit: Also I assumed you meant restore on after AC loss, and not the last state.

What you're describing works but probably not for me as you acknowledge. The "PC loses AC while running" part is what I actively try to avoid as part of the greater goal of minimizing risk of damage/data loss. It might be superstitious at this point, modern hardware and filesystems being a bit more resilient, but I feel better not risking it. Since I'm shutting down before the UPS battery dies, and power could restore before it does, there's a real chance power will never be totally lost as far as the motherboard sees it. In that case a boot on AC restoral won't get triggered. Otherwise I agree. It's a lot of work. Or rather a lot of research, RTFM, and understanding before you can even do the a little bit of work to implement it.