A process running as root has more extensive access to various system calls, which increases the attack surface area. Even if SELinux is correctly enforced, there will still be an increased risk of kernel exploitation. The reason for this is that many system calls have checks to ensure that the process is running as root (more specifically, the checks are usually for
CAP_SYS_ADMIN). If the process lacks those permissions, it quickly returns
EPERM or a similar error. If it has those permissions, then a bug in between the quick permission check and the much later LSM checks can allow a process to exploit the kernel and disable SELinux, or more.
A privileged process may be able to take actions which SELinux cannot restrict due to there being no appropriate LSM hooks, which mandatory access controls tend to rely on. These hooks are scattered throughout the kernel and, each time they are reached, check whether or not the LSM has restricted the action. For example, after DAC checks (standard Unix permissions), an LSM hook exists that checks whether or not accessing a given filesystem object is permitted. Because the kernel is so complex and has such an extensive relationship with userspace, it is not possible to restrict everything. For one example, the risky
ioctl system call (a catch-all syscall against file descriptors which allows kernel drivers to register what is in effect their own system calls) is not restricted by SELinux. In order to provide more fine-grained restrictions, you would need to whitelist the individual syscalls and their arguments. This can be done using the seccomp syscall filter.
No matter how tight you think your SELinux policy is, there is always room for improvement. For example, do you restrict the process' resource limits? Root processes are able to override resource limits, which can have security implications (for example, it is possible to disable ASLR for newly executed processes if you are able to control the stack resource limits).
Overall, there are four main risks that I can think of when running a process as root:
As explained above, the increased attack surface area may be exploitable.
The lack of defense-in-depth will mean that a bug in SELinux could lead to exploitation.
SELinux is not able to hook every possible action a root process can take.
No matter how tight the policy is, it can always be improved (e.g. do you restrict rlimits?)
Unless it is prohibitively difficult to run the daemon as its own user, I would suggest you drop privileges appropriately as if you were using no access control system at all.