That depends on how you define "substantially" and "better". Consider cat.c from gnu [0] and openbsd [1]. I'd say that openbsd's implementation is "substantially better", because:
1. it does everything I need in 194 LOC (vs 488 LOC)
2. the code is so understandable that it needs no commenting (and I'm not just saying that because it has no comments, it is braindead simple code)
3. there are no ifdefs and the program state is much more shallow
Now obviously that is from the perspective of a programmer, but it has been my experience that if the code base sucks for programmers - then things suck for the users as well (surprising behavior, security issues, long lag in bug fix, etc). I once spent a day chasing a bug related to autotools and colorized output from grep... sometimes the bells and whistles get in the way of actually getting things done.
While I appreciate the value of a cleaner or simpler codebase, I can't place as much value on that as I do on usability, unless the code is utterly unmaintainable beyond all hope of redemption. And whatever you might think of the extra complexity of the GNU code, for good or ill, it certainly isn't that.
Again, a lot of words with definitions that intelligent people can disagree on. This is why there are so many different operating systems... and implementations of echo.c. So to answer your original question more directly : yes, there are many instances of the standard command-line tools available on other UNIXen being substantially better than the GNU userspace tools. In my opinion. You may disagree, but who is to say?
1. it does everything I need in 194 LOC (vs 488 LOC)
2. the code is so understandable that it needs no commenting (and I'm not just saying that because it has no comments, it is braindead simple code)
3. there are no ifdefs and the program state is much more shallow
Now obviously that is from the perspective of a programmer, but it has been my experience that if the code base sucks for programmers - then things suck for the users as well (surprising behavior, security issues, long lag in bug fix, etc). I once spent a day chasing a bug related to autotools and colorized output from grep... sometimes the bells and whistles get in the way of actually getting things done.
[0] http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat...
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/cat/cat.c?r...