That the code "runs as root" is mostly irrelevant. Root or non-root is a distinction that makes sense only locally to a machine, and only if you want to contain some potentially hostile code (e.g. hijacked server code) without bringing down the whole machine. This is the mainframe model from a few decades ago. At that time, it was believed that you could have a Unix (or Unix-like) system such that non-root process could be kept apart from each other, without any possibility to evade that containment and reach other process on the same machine.
This belief hardly holds nowadays. Local privilege escalations are plentiful; it is very hard to plug them all while maintaining a fully functional environment. In general, it is safer to assume that any hostile code running on the machine, under any user, will be able to take control of the whole system, unless some stronger containment measures are applied, such as (in increasing levels of complexity and containment) chroot, jail, virtual machines. In any case, a process that calls mmap() on
/dev/mem can gain full control on the local machine (possibly the virtual machine if you go the VM road).
The conclusion of all that is that if your machine is hacked into, and making it Internet-facing sure increases that likelihood, then you should ask yourself what could happen if it gets subverted by hostile outsiders. Changing the code not to run as root and not to mmap
/dev/mem does not substantially change things here. What matters is whether the code has been well designed, reviewed, tested, documented and maintained.
I must say that a direct
/dev/mem sends a strong signal of "these guys should not be allowed to go near a keyboard". I don't know why you are doing that in your server(*) but it seems real weird. Mapping physical RAM in your address space is not a security issue, unless you cling to the outdated mainframe model; however, doing very funky things is a security issue because it makes design, reviewing, testing, documentation and maintenance much harder.
(*) My best guess is that your server interacts with a custom piece of hardware that lacks a specific kernel driver, and does I/O by mapping its circuitry in the physical address space, like, say, a graphics card. It would be cleaner, and thus safer, to actually write an appropriate kernel driver.