Though in this case I would simply name the script steam-launcher and call it a day

The problem with that is that if another application tries to launch steam, it will bypass the script. And renaming the steam binary and give the original name to the script means that it has to be done every time steam is updated. Not to mention that if the script has a different name from the binary and I were to launch steam from the terminal to troubleshoot something it would also cause the issue again.

Having multiple executables with the same name and relying on $PATH and absolute paths feels hackish to me

https://github.com/ValveSoftware/steam-for-linux/issues/1890

The last comment in that issue is mine, compare my solution to the other solutions that people came out with and you will see it is the least hacky one, before I was even trashing the steam files if it had been launched accidentally in the wrong location lol.

Also this is how snaps and appimages integrate into the system. You add their location to PATH and it is done. You don't even need sudo to do these changes.

there are better options. I mean something like a bind mount

Do I need elevated privileges to do that?

I’m not saying we should get rid of $PATH right now.

I don't think we should ever get rid of it, the reasons it may have been created may not be needed today, doesn't mean it is no longer useful, like the several examples I just gave you.

Do you think the same of LD_LIBRARY_PATH? It is very useful for locally compiled applications, like i3 for example, which I compile and install into my system with a patch that is not merged into the released i3 package. Because installing it into the system /bin and /libs causes my package manager to complain that certain files already exist when updating/installing other applications.

Also do you feel the same about the XDG Base dir spec? like for example XDG_DATA_HOME, XDG_CONFIG_HOME, etc are environment variables like PATH which let you move their location around.