The accepted answer is inaccurate. My answer may also be questionably accurate or hard to follow, but it seems worth sharing. :) This kernel option determines if anyone can just "echo 0 > /proc/self/loginuid" when loginuid is unset and then it remains unchanged, or if modifications to that value require a specific capability regardless of current value. When this is true (which typically means you're root), loginuid can only be modified if it's unset. The reason the accepted answer is inaccurate is that sudo and su are typically both suid root. They are suid root in order to allow the binary to switch to a different effective UID. In most Linux systems, the root user has all capabilities by default. Therefore, those programs also have the capability of switching the loginuid attribute if this is false. If this is true and the system is properly configured, loginuid should have been set in the login shell by ssh/login/whatever, and nothing can change the value.
The loginuid attribute is unset at system startup / within init. It is typically first set by the pam_loginuid module on "entry point" services. So, you set up ssh and login to set a value, as those are things which would allow someone to "log in" - hence loginuid. You wouldn't include the module in the sudo pam stack, for example, because that's not a new login; that's switching UIDs after logging in. The purpose of loginuid is to track a user from login time. You can use the audit daemon to record processes run by a specific user, even after they've switched accounts with su or sudo. The logname utility uses this attribute on newer systems to identify the "logged in user" independently of the effective or real uid values (older systems use the controlling terminal to look up a login event from utmp).
Processes inherit the loginuid attribute from their parent process, BTW.
So, this parameter controls whether the loginuid attribute can be modified. It mentions systemd because of how init works. The kernel starts init, and init has no loginuid. Then init starts services, and those have unset loginuids. With regular System V init, an admin might log in and, say, run "/etc/init.d/someservice restart". The admin's loginuid attribute is set when they ssh in, and that carries forward to switching to root. Then they run the init script, which inherits their loginuid. If the "loginuid immutable" value is set, the init script or admin can't make the system call which either clears or resets the lognuid attribute before starting the daemon, and now the daemon is running with the admin's loginuid, screwing up audit logs, etc. If the value is modifiable, then there is a system call (audit_setloginuid()) which can be made by a process with appropriate capabilities (perhaps /sbin/service, for example) to clear or set a reasonable value for loginuid on the given daemon.
The way systemd (and upstart, and perhaps some other init systems) work, the admin doesn't directly run the init scripts. Instead, the admin sends a command to the init process, and the init process then does the restart (or whatever) action on its own. Since init has an unset loginuid, the spawned init script inherits that value (unset), and then the init script can set its own loginuid even though it may have been run as a non-root user. It's arguably more secure, since nothing needs special capabilities; everything can be done as a regular user.
So, if you have a decoupled init system, there is generally no legitimate reason for anything non-root to be changing the loginuid attribute once it's initially set, and thus it can be set essentially immutable.
To answer the question about "what does this give you," well, not much. There are probably programs out there which grant access based on the loginuid rather than the uid or euid, but those are few and far between. In general, access is controlled based on SELinux contexts, EUID, UID, or process capabilities. Changing your loginuid to 0 shouldn't get you anything - and should probably trigger a monitoring system designed to catch remote root logins. :) Some sites use auditd to track process execution / system calls, and those sites may well need loginuid to be accurate in order to have working system audit rules. But if you're asking this question about a kernel you're compiling, you are not operating one of those sites. :)