Shell scripting (in this case Busybox) is a viable approach to developing robust, long running embedded systems.
If you can afford to run a (multi-tasking, memory managed) Linux kernel in your embedded system and Busybox is there, then the shell (ash in this case) becomes a potential basis for a system architecture.
Of course, this is not breaking news. But I think it gets lost when we start taking a " single programming language" view of system development (as advocated by almost every modern programming language). If you are trying hard to figure out how to get your favorite programming language to do what the shell does, then maybe it isn't the right tool for the job.
Sure, the "shell" isn't elegant and is full of pitfalls and gotchas when you use it beyond a couple of lines, but when your shell script starts to grow, you too should consider looking elsewhere for help (i.e. commands beyond what is built into the shell).
An example: Don't get caught up in gawk/bash's ability to read from TCP sockets, leverage netcat (nc).