I've read this thread fairly thoroughly, but fail to see much of a use
case...

There's hypothetical stuff, what if service x needs service y. Well, what
if it does. Should it demand that y be running at every moment and on the
same host? DOES it demand that?

This isn't a good thing to spend effort on. The trend today is towards
services that require only an OS absolutely. A modern service requires e.g.
a read/write file system and/or a network interface with addressing and
routing. If a modern service uses something like an SQL database, it'll
paper over inavailability, it'll delay, retry, reconnect.

The fashionable rationale is cloudy wizbangery. But a notable side effect
is that postgresql and services that use postgresql can start at the same
time.

I'm not saying that ALL services cope with unavailable dependencies. What I
am saying is rather that spending effort on supporting this kind of
dependency management has low and decreasing value. AWS and other systems
that provision instances according to need push strongly on server software
to cope with momentary inavailability, odd starting order, etc.

Arnt