Especially in the Linux/POSIX world, daemons that need some root capabilities for temporary initialization purposes only (e.g., to read a root-owned private key file, or to open a port<1024, or to increase resource limits), often seem to follow a design pattern where they change their credentials with function calls such as setuid()/setresuid() and setgid()/setresgid(), and then call fork() to run the actual program as its child. Supposedly the fork()-ing is done "just in case", but what is or was the actual security consideration for doing so?
And to follow up on that, is that reason still relevant when (in addition to setgroups(0, NULL), setresgid(GID_NOBODY, GID_NOBODY, GID_NOBODY) and setresuid(UID_NOBODY, UID_NOBODY, UID_NOBODY)), the program is also proactively limiting Linux capabilities, by dropping every capability as soon as it is no longer needed, by calling cap_set_proc()?
Do you have any particular example?
Normally the daemon forks and retains root privileges in the "master" process. This is useful because this means it can e.g. reload the configuration and possibly bind to other ports. Forked children are unprivileged and handle the actual traffic.
My guess is that you saw a program which dropped privs, forked and exited in the parent. If so, this was done as a part of becoming a daemon.
Well best practices in security recommends to have many defense lines.
If you were sure that your daemon has no flaw in it, nor have any of the functions of library that it uses, you could let it run with full privileges without any more risk.
But if it has been written by a mere human being, chances are that it hides some possible exploits that could allow an attacker to have it execute arbitrary code. One was discovered in SSL library not so far from today, not speaking of Windows...
That's the reason why you should revoke all privileges that are not required for processing external input, because risks are higher in that part.
That's all for the dropping of privileges. The fork part is normally used to split the daemon into one highly privileged process that never processes external output (security...) and that monitors other low privileged process[es] that do the real job. For example, it allows to restart a child that died or became stuck, but external input data is never processed by privileged code.