What you've said basically echos the stuff I was thinking when I read this - I don't really see from this article how having a userspace daemon is necessarily an improvement. Maybe there's more to it.
Having the kernel handle mechanisms and userspace daemons handle policy is a well established practice and a very sensible one. So having a daemon of some kind that sets up policy or can be consulted to make policy decisions seems reasonable. In this instance, though, it sounds like the userspace process is also handling part of the mechanism too. The kernel's machinery is apparently not suitable for applications to request realtime privileges, so that goes through the daemon too. This looks a bit awkward to me, as it suggests that a daemon has been created to compensate for a lack of kernel flexibility.