My question is: why three days specifically instead of a user-configurable delay?
replies(2):
If you were to allow a user to change it, you'd have to safeguard the channel by which the users' desired delay gets pushed into the SE against malicious use, which is inherently hard because that channel must be writable by the user. Therefore it opens up another attack surface by which the inactivity reboot feature itself might be attacked: if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless.
It's not impossible to secure this - after all, changing the login credentials is such a critical channel as well - but it increases the cost to implement this feature significantly, and I can totally see the discussions around this feature coming to the conclusion that a sane, unchangeable default would be the better trade-off here.
Then why not simply hardcode some fixed modes of operation? Just as an example, a forced choice between 12, 24, 48, or a maximum of 72 hours. You can't cheat your way into convincing the SE to set an unlimited reset timer. I'm sure there must be a better reason.
Plus, vulnerability often follows complexity. Whether it's human written validation logic being attacked for 6 months in a lab somewhere in Israel or the overly complex UX exposed to some soccer Mom in Minneapolis.
Save money. Save headaches. K.I.S.S.