It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc.
Yes! I was surprised how far down I had to scroll to find somebody mentioning that one.
How else can you write a reasonably robust script that actually, you know, does something? You almost always need to grab some known files by their paths relative to the script.
argv[0] isn't actually a great solution for that since it isn't required to contain any path and in practice won't depending how the program was called.
Some languages don't provide a better solution but they should. For Bash there is ${BASH_SOURCE[0]}. For compiled executables you use OS-provided functions like GetModuleFileName(NULL, ...) on Windows and readlink("/proc/self/exe", ...) on Linux.
The point is that using argv[0] to get the executable location can be quite fragile in practice and there are (OS-specific) alternatives that work much better for that goal.
It's not fragile at all. It's also cross platform without 18 ifdefs. It also doesn't necessarily or only tell you where the exe is, it tells you what was called. And maybe you want to know that. If sometimes you don't, so what? No one can say for anyone else that they do or don't need this bit of info, or should or shouldn't make assumptions based on it. The fitness for purpose is 100% context dependant. You have to be looking at some particular app and the rest of the environment it's running within before you can say "argv should not be consulted here, we should use this other interface instead" You can't say anything like that as a general case that automatically applies to everything.
Yes! I was surprised how far down I had to scroll to find somebody mentioning that one.
How else can you write a reasonably robust script that actually, you know, does something? You almost always need to grab some known files by their paths relative to the script.