This is an "as if" rule.
Simply put: The behaviour of the shell as users see it should not change if an implementation decides to make a standard external command also available as shell built-in.
The contrast that I showed at https://unix.stackexchange.com/a/496291/5132 between the behaviours of (on the one hand) the PD Korn, MirBSD Korn, and Heirloom Bourne shells; (on the other hand) the Z, 93 Korn, Bourne Again, and Debian Almquist shells; and (on the gripping hand) the Watanabe shell highlights this.
For the shells that do not have
printf as a built-in, removing
PATH makes an invocation of
printf stop working. The POSIX conformant behaviour, exhibited by the Watanabe shell in its conformant mode, causes the same result. The behaviour of the shell that has a
printf built-in is as if it were invoking an external command.
Whereas the behaviour of all of the non-conformant shells does not alter if
/usr/bin is removed from
PATH, and they do not behave as if they were invoking an external command.
What the standard is trying to guarantee to you is that shells can build-in all sorts of normally external commands (or implement them as its own shell functions), and you'll still get the same behaviour from the built-ins as you did with the external commands if you adjust
PATH to stop the commands from being found.
PATH remains your tool for selecting and controlling what commands you can invoke.
(As explained at https://unix.stackexchange.com/a/448799/5132, years ago people chose the personality of their Unix by changing what was on
One might opine that making the command always work irrespective of whether it can be found on
PATH is in fact the point of making normally external commands built-in. (It's why my nosh toolset just gained a built-in
printenv command in version 1.38, in fact. Although this is not a shell.)
But the standard is giving you the guarantee that you'll see the same behaviour for regular external commands that are not on
PATH from the shell as you will see from other non-shell programs invoking the
execvpe() function, and the shell will not magically be able to run (apparently) ordinary external commands that other programs cannot find with the same
PATH. Everything works self-consistently from the user's perspective, and
PATH is the tool for controlling how it works.