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?

This is quite a tricky question, as with anything related to the setuid mess.

A normal user can only set its euid to its own ruid.

I can only come up with the case you've mentioned for unprivileged usage then: a SUID executable to another user (maybe not root also) and a call to setuid to whatever real user id was before, this would be a clunky way to start doing some maneuver that requires that SUID privilege and drop them midway or just a reassurance that you're not doing something with higher/different privileges and got pwned.

It might be a good idea to check if it's used in that way in the utilities. I couldn't find anything in the lion's book ( https://warsus.github.io/lions-/ ) but a quick search using whatever github repo hosts the v6 code may indicate that:

https://github.com/memnoth/unix-v6/searc...d_q=setuid

For instance, login or mv.

https://github.com/memnoth/unix-v6/blob/...s1/login.c
https://github.com/memnoth/unix-v6/blob/...ce/s2/mv.c

Before any tricky operation it reassure itself that it doesn't have an effective user ID with elevated privileges by forcing it to reassign it to the real user ID.

Those are only guesses by looking through the code, maybe someone here has a better explanation.