I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accidentally breaking existing #! lines that used to work.

▲ chuckadams 7 hours ago | parent [-]

> plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does)

glibc is what deals with PATH, not the shell. On Linux, it's execvp(3) in libc which is implemented in terms of execve(2) in the kernel, but POSIX doesn't make a distinction between syscalls and library functions, so a kernel could implement either or none directly.

	▲	stabbles 6 hours ago \| parent [-]
		To be fair, many shells have command caching, so they effectively roll their own exec syscall wrapper: `$ python3 -c 'print("hi")' hi $ hash hits command 1 /usr/bin/python3`