All the commands that a user might want to run are in the PATH. That's what it's for. This includes commands that you run directly, commands that other people run directly, and commands that you or other people run indirectly because they are invoked by other commands. This is not limited to commands run from a terminal: commands run from a GUI are also searched in the command search path (again, that's what it's for).
Needing to type the full path would be terrible: you'd need to find out what the full path is! You'd need to keep track of whether it's in /usr/bin
(which contains most programs shipped with the operating system), or in /usr/local/bin
(which contains programs installed manually by the administrator, as well as programs that aren't part of the core OS on some unix variants), or in some other system-specific directory, or somewhere in the user's home directory.
It's difficult to answer about the “impact on performance or maintainability” because you don't say what you're comparing it to. If you're comparing with having to type the full path everywhere, that's a nightmare for maintainability: if you ever relocate a program, or if you want to install a newer version than what came with the OS or was installed by a system administrator, you have to replace that full path everywhere. The performance impact of looking the name in a few directories is negligible.
If you're comparing with Windows, it's even worse: some programs add not only the executable, but also all kinds of crap to the PATH, and you end up with a mile-long PATH
variable that still doesn't include all programs, because many programs don't add themselves to the system PATH when you install them.
The part that strikes me about it is I like to have small and descriptive namespaces when I think about programming, while here everything is sort of in the same global namespace (and, when we do look at full paths, in quite nondescript places like */bin). I guess they are pretty different things, though.
– Dylan McCall Aug 16 '12 at 05:12