Network connectivity dependencies
Many system services and applications depend on network connectivity. Either all or some of their functionality requires connection to a local network and/or the internet.
Some developers tend to think that dependencies should be resolved by the init system or the service manager (for example systemd or OpenRC). This only ever worked well for servers with static network configuration. It never worked well with DHCP. And the demand for dynamic networking features is much stronger nowadays.
Many of the current network dependency problems cannot be solved in initscripts or systemd unit files. Certain level of cooperation is expected from the actual services and applications.
Note: Gentoo's OpenRC has a notion of inactive services. That means NetworkManager can be running but marked inactive until it activates a successful connection and switch back to inactive on disconnection. This allows OpenRC to manage basic dependencies on the connected state. This is AFAIK impossible with systemd.
Passive listening servers
Server processes whose only purpose is to serve clients connecting over the network are the simplest case. They don't need to depend on network connectivity at all due to a marvelous invention called wildcard address.
They can start at any time, even before the network configuration service and start listening for new connections. One of the biggest advantages of this approach is that it can immediately answer queries from localhost and, as soon as network interfaces are activated, from local neighbors through link-local addresses.
Software listening on the wildcard address effectively avoids any network dependencies.
Long-running clients and peer-to-peer services
Some software is expected to be running the whole time the computer is connected to the network and actively contact other network hosts. An example of such a software is ntpd or chronyd on the system level, and telepathy on the session level.
There are several ways to handle long-running clients:
1) Run them only when global connectivity is available. This is often problematic as some of the clients could benefit from node-local networking, link-local networking or even running without network (e.g. ntpd).
2) Run them at startup. Restart them whenever a new connection is established to force them accomodate the situation. This is how bind is being handled now, even though it is a server and shouldn't need that at all.
3) Run them at startup, let them follow what's going on. They can use NetworkManager's D-Bus API, Linux Netlink interface or they could use a more generic library.
Neighbor discovery services
Peer-to-peer discovery services like avahi need to have precise knowledge of what's going on with the network interfaces and addresses. Their situation is basically the same as with long-running clients that require solution #3.
Listening servers with connectivity magic
Some servers might need to listen on a non-wildcard address or require knowledge of network configuration for any other reason. Their requirements are basically the same as for neighbor discovery daemons and clients which require solution #3.