A command loaded into your process can do things to you if you run it directly without calling spawn() or pctl(), but you'll usually use those to seperate the process, although it's rare to do it that way.
As far as other shells in the family, mash influenced Inferno's sh, but I think it's a relatively sparse branch compared to bourne-compatible shells.
What's the advantage of doing everything in the same process? Your article said this is nicer but I don't see what the advantages are and there are some disadvantages I listed (ABI issues, security).
Well, spawn() and pctl() are actually more like a finer-grained fork(), without the necessity of, for example, O_CLOEXEC, or anything in fcntl. Between pctl() and Limbo's channels (on which Go's are patterned), a lot of what is required for security in "vanilla" Unix is unnecessary.
What I was trying to convey in the article (sorry if it was a bit vague) was that using functions available to the shell was the nice part, the actual advantage over regular Unix. That is to say, if a user passes '*[0-9]?.gz', you can call functions within the shell to handle the glob rather than having to implement them yourself, for example. The shell is also designed as a library, in other words. This includes things such as parsing sh's syntax, even.
A command loaded into your process can do things to you if you run it directly without calling spawn() or pctl(), but you'll usually use those to seperate the process, although it's rare to do it that way.
As far as other shells in the family, mash influenced Inferno's sh, but I think it's a relatively sparse branch compared to bourne-compatible shells.