But being a single binary it also is a single point of failure.
Even a standard user land has tons of those. Corrupted libc? Missing dependencies? Too bad.
Why don't just use a standard user land instead of busybox on such machines?
The beauty of busybox (and its alternatives such as toybox) is that it's small, simple, and quite sufficient for the task. It works, so why use something else?
It's used on any desktop PC too, as part of the initramfs, again for simplicity. While you could duplicate a real userland there, it would just blow the kernel/initramfs size beyond proportion. And a larger initramfs means longer load times and a slower boot process.
For firmware vendors, it's also easier to keep track of a single project, instead of doing what Linux distributions do, trying to make various components fit and work together and tracking bugs for each of them...
Of course busybox also has its limitations, for example it's difficult to compile a Linux kernel in a busybox environment, since some functions are simply missing (ar for example is lacking some options the kernel wants to use). But for initramfs or smartphones, such limitations don't matter.
