And I would guess sysadmins also don't like their logging facilities filling the disks just because a service is stuck in a start loop. There are many reasons to think a service failing to start multiple times in a row won't start. Misconfiguration is probably the most frequent reason for that.
I'm sure there are exceptions to this. For those, set Restart=always. But it's an absolutely terrible default.
This is one of those things.
The 'After=' and 'Requires=' directives address this.
Depends on a mount? Point those directives at a '.mount' unit.
Depends on networking, perhaps a specific NIC? Point those directives at 'systemd-networkd-wait-online@$REQUIRED_NIC.service'
Point being: declare these things, don't wait for entropy to eventually become stable.
Back on point though: don't expect the 11th restart to work when the last 10 didn't.
Contrived examples are contrived, it's solved. Declaring dependencies.
With the requirements properly laid out we've avoided restarting in a loop and a bit of robustness
There's also 'PartOf=' which can help make the relationship bidirectional
Starting up, noticing that the environment doesn't have what you need yet and dying quickly appears to be The Kubernetes Way. A scheduler will eventually restart you and you'll have another go. Repeat until everything is up.
The kubelet operates the same way afair. On a node that hasn't joined a cluster yet, it sits in a fail/restart loop until it's provisioned.
(You can guess how we noticed the problem…)
Also logrotate. (And bounded on size.)
Before=systemd-user-sessions.service
This means that as long as systemd is trying to (re)start the service, nobody can log in. Which is a problem with infinite restarts.
It's still pretty easy to accidentally set up an infinite restart loop with the default settings if your service takes more than 2s to crash.