The Debian technical committee vote concludes

No, the post you were responding to was not about servers; the topic was about workstations by that point. This is a crucial difference, because workstations often don't even have any kind of remote network access configured at all, and even when it is, it isn't the normal way to access them.

As it happens, I was actually bitten very mildly[0] by this problem last weekend while trying out OpenSUSE, though at the time I just assumed it was the distro that had made the weird choice of default. The situation there is that shutdown had apparently hung, and I wanted to reboot the machine without just hitting the reset button.

Doing that remotely would have required that I'd enabled the ssh server (not sure if I'd got that far), go downstairs, turn on my partner's computer, see if I could guess her password, download an SSH client, get my SSH key from a backup, and finally log in to the machine in question and start the laborious process of sending signal 15 to every process (I'm sure there's an easy way to do that, but I don't know it because the magic sysrq key has always been the easiest way to do it). Except that I'm pretty sure this happened after the network had been brought down, so all that would have been for naught.

Contrived? Maybe, but certainly less uncommon than somebody trying some kind of shared kiosk system using only out of the box default configurations.

>For no real change in your ability to recover servers
Somebody obviously thought this feature was a real change, for it to have been implemented in the first place

>you gain physical access to the keyboard no longer providing the ability to trivially DoS the running system.

One: You don't actually gain that, because that requires so many other changes that setting this one option is trivial in comparison. It is obviously the case that the default set up for any system requires that a person with access to the keyboard be able to reboot the machine, and changing that for some specific use case is going to mean massive changes to the running environment. So why bother setting just this one option, probably the easiest part of the job, when the actual task you appear to be doing it *for* is so much larger?

Two: You are giving some highly contrived example of an extremely specific, wildly unusual custom requirement, and using it as an explanation for changing the default for everyone. This is exactly the kind of thing people are talking about when they complain about insane defaults; defaults should be selected for the common case, not the most weird case you can think of, *especially* when that case will require enormous additional work anyway.

Both of these two points apply to servers just as well as workstations BTW, however for servers the effect is mitigated somewhat because remote login is a more realistic scenario.

[0] I say 'very mildly' because in this case it was a test system where I didn't care much about the outcome, and waiting a few minutes for some timeout to happen allowed it to continue anyway. The problem is correlated with having cifs shares in fstab, and I think the issue is that systemd doesn't know that bringing down the network needs to be done *after* unmounting those shares, but I've not yet investigated what the recommended modern way is of configuring network mount. Probably not 'just stick it in fstab like it's 1999', anyway.