In many cases, the security impact of bugs can be reduced by following the principle of least privilege.
For instance, the BIND name server does not really have to run as root all the time. It needs root privilege to bind to port 53 at startup, but that's it. Afterwards it needs read access (and, if it's a secondary server, write access) to the zone files, and that's it. So security is improved vastly by creating a user named bind and making named drop root privilege and become user bind after setting up its sockets. Of course, the zone files and the directories they're in must also be owned by bind if you run a secondary name server; otherwise it's enough to just give it read access.
A second example are network services like talk and finger; for years, Linux distributions have shipped inetd configuration files that started these services with root privilege. If you look at the facts, the talk daemon needs group tty privilege in order to open the tty of the user he should talk to. Finger doesn't need special privilege at all; it just wants to display files from a user's home directory. So why not run these services with tty and nobody privilege? That's enough to let them do their job; and in the case there is a security problem with them, attackers do not instantly gain super user privilege.
You should be careful with the nobody uid however. This is a very special uid that should not be used too much. Assume you've managed to modify all your network services so that they run under the nobody account. Now if an attacker manages to break one of your services, all it gives him is nobody privilege. However with all those network processes running under the same uid, this becomes a powerful tool because he can now attach to these processes using ptrace(2), modify their memory, etc. So if you have modified a network server to run with reduced privilege, think about creating a new system user specifically for this service rather than overloading nobody.