One reason why people sometimes execute network services as superuser (i.e., root) is the fact that Linux, like most operating systems, doesn't allow non-privileged users to bind sockets to the so-called System Ports (a.k.a. Well Known Ports or privileged ports).

One can't say that this is generally bad practice, as many network services make use of privilege separation to mitigate potential security vulnerabilities. (Usually, privilege separation is done by making use of setuid(2), setgid(2), or related system calls, which are standardized in POSIX.1-2001.)

If no privilege separation technique is applied, running network services as superuser is bad practice.

Unfortunately, people are often confronted with the problem that they would like to allow an application to bind sockets to System Ports, but the respective application doesn't do privilege separation.

Fortunately, Linux provides a privilege separation mechanism known as capabilities(7) that works on the operating system level. Here are the probably most relevant parts from the man page:

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

[…]

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability.

As you can find out from the capabilities list in the man page, the capability to to bind sockets to system ports is CAP_NET_BIND_SERVICE. Using setcap(8), it can be assigned to an executable file some-executable like this, for instance:

    sudo setcap cap_net_bind_service=+ep /full/path/to/some-executable