First, a clarification:
It requires to have root privilege to change permission to a file.
From man 2 chmod we can see that the chmod() system call will return EPERM (a permissions error) if:
The effective UID does not match the owner of the file, and the process is not privileged (Linux: it does not have the CAP_FOWNER capability).
This typically means that you either need to be the owner of the file or the root user. But we can see that the situation in Linux might be a bit more complicated.
So, are the any relationships between root and kernel?
As the text you quoted has pointed out, the kernel is responsible for checking that the UID of the process making a system call (that is, the user it is running as) is allowed to do what it is asking. Thus, root's superpowers come from the fact that the kernel has been programmed to always permit an operation requested by the root user (UID=0).
In the case of Linux, most of the various permissions checks that happen check whether the given UID has the necessary capability. The capabilities system allows more fine grained control over who is allowed to do what.
However, in order to preserve the traditional UNIX meaning of the "root" user, a process executed with the UID of 0 has all capabilities.
Note that while processes running as UID=0 have superuser privileges they still have to make requests of the kernel via the system call interface.
Thus, a userspace process, even running as root, is still limited in what it can do as it is running in "user mode" and the kernel is running in "kernel mode" which are actually distinct modes of operation for the CPU itself. In kernel mode a process can access any memory or issue any instruction. In user mode (on x86 CPUs there are actually a number of different protected modes), a process can only access its own memory and can only issue some instructions. Thus a userspace process running as root still only has access to the kernel mode features that the kernel exposes to it.