Complexity is the death of usability. There comes a point in design when you must ask: `does the task at hand justify this complexity', `is this level of complexity necessary for the goal of this design'. Complexity is a necessity, not a desirable feat; and the complexity of a solution should always scale linearly with the complexity of the problem.
The task of design and implementation is not to find a solution to the problem; the task is to find the most simple (efficient) solution.
Simplicity and efficiency are not the same, but often go hand in hand.
For example, if a server owner has to set up and configure 4 different daemons for a task that could be completed by 1, the system is not only needlessly complex and difficult to configure, but inefficient due to constant inter-process piping of information and sharing of resources between daemons, as well as static libraries that may be loaded more times than is needed and such. In contrast, the creation of many small programs for a task that could be completed by 1 is not necessarily over-complex, but is still inefficient because the overhead of a process call actually can be significant. (Even in 2018, these things can stack up. 10 process calls may be fine, but 10000? 100000? You will begin to notice the problem of scaleability eventually.)
Complexity of configuration is often overlooked with `oh well you should know more about the system then, it's your own fault things went wrong' but I disagree. Increasing complexity of configuration makes errors more prone, errors that are often silent or hard to detect, errors that can manifest in security holes that are easy to overlook because of the sheer volume of configuration required. Does this socket have the correct permissions? Is this file readable is this one writable? Is this port in use by another server? Is this daemon loaded correctly? Alone these may seem easy to keep track of but can get overwhelming when having to configure many daemons together.