This post refers to AT&T Research Unix version 6 (1975). I am hoping
that someone can explain the purpose of setuid's unprivileged behavior.

From the Sixth Edition Programmer Manual.

DESCRIPTION
The user ID of the current process is set to the argument.
Both the effective and the real user ID are set. This call
is only permitted to the super-user or if the argument is
the real user ID.

From the Lions book.

setuid()
{
register uid;

uid = u.u_ar0[R0].lobyte;
if(u.u_ruid == uid.lobyte || suser()) {
u.u_uid = uid;
u.u_procp->p_uid = uid;
u.u_ruid = uid;
}
}

suser()
{

if(u.u_uid == 0)
return(1);
u.u_error = EPERM;
return(0);
}

An unprivileged caller is only permitted to assign the real user ID to the
effective user ID. For a standard root:root suid, this was insufficient
for reacquiring root privileges. The (r:0,e:0) process would setuid to
a luser (r:1,e:1) and then setuid would be a noop or error. AT&T eventually
solved this problem with saved-set-UID. BSD Unix implemeneted setreuid to solve
the same issue.

One (unconventional?) use case I can identify; a (r:0, e:0) process execs
an suid owned by a luser (r:0, e:1). Then the process uses setuid to reacquire
root (r:0, e:0).

Was there a standard usage of this unprivileged behavior?