I'ma regular contributor to the TomatoUSB firmware, so I have more than enough familiarity with Busybox.
squashfs is partially the reason Busybox is used this way. To clarify,
squashfs supports both hardlinks and symlinks. Further proof is in this
incorrect problem report. Hardlinks could have been used just as effectively -- and in some firmwares they are used instead of symlinks. What I do not know is what the compression level difference is between a symlink and a hardlink with squashfs. It varies based on inode type (dir vs. file vs. symlink vs. hardlink vs. FIFO etc.), so there may be an advantage compression-wise to using symlinks over hardlinks.
From the Busybox perspective it doesn't matter though -- the main busybox binary itself parses argv[0] and iterates over a large array of strings, comparing against the effective calling command was. Rather than get into the parsing semantics, it works like this: if you symlink or hardlink "poop" to the busybox binary, and you run the "poop" command, the busybox binary compares the command you run to argv[0] and if it finds a match, it runs the code associated for that command. If there is no match, I believe busybox spits back some error like "unsupported command".
This is exactly what FreeBSD's /rescue/rescue does too, it's just done (implemented) differently internally -- the binaries you see that are hard linked to /rescue/rescue are not "custom versions" like what you find with Busybox -- they are the real deal.
So there's a single binary on the system that handles lots of commands. Why is it done this way?
That has to do with saving space on a filesystem like squashfs, quite simply. Remember: Busybox "markets" itself for embedded environments or where space is very limited.
{opinion}
Other than that, Busybox is just a total piece of utter junk. I cannot even begin to explain to you the amount of bugs and brokenness that are in this suite. I think my bug list, personally experienced, is up to 40 or 50 by now, and I have fixed my own share of catastrophic bugs in that junkpile more than once (my favourites usually consist of file descriptor leakage, i.e. someone not calling close() but repeatedly calling open()). A colleague of mine personally knows a developer who quit the Busybox team after several years, simply because of how utterly horrible the code was that was being pushed out. That fellow now works on something called Toybox. Any time I see Busybox used somewhere I become wary and scared.
{/opinion}quote:
EDIT: I see what they're doing! Creating the most survivable, smallest footprint, of recovery tools.
More or less, you got it. I wouldn't use the word "survivable" though -- it's just about saving space in environments where space is not as freely available as, say, a 250GB hard disk.