Main problem with extra commands is that there are more to
learn. Redundancy like this basically pollutes the namespace
and makes things much harder to learn. In other words more
than one (equivalent) way to do something is bad.

This is equivalent to the difference between the windows
and UNIX APIs. UNIX is narrow and general, whereas windows is
broad and specialised. So IMHO we should always be trying to
refactor everything into cohesive units with narrow/general interfaces. 

Obviously you can't throw away existing utilities, for backwards compatability
reasons, but you can provide mappings, and also encourage the use of the more 
general tools. The mappings can be done with aliases/scripts/or checking
of argv[0] (the command name). While we're taking about argv[0] handling,
it seems obvious that the commands below should be in 1 file with links
    fgrep,egrep,grep
    ls,dir,vdir 
    sleep,usleep (sleep=sh-utils, usleep=initscripts)
However it's gnu policy to split even these up into seperate
files, rather than link them. The reason given is that users may 
want to copy them to different names. However this is trivally supported 
using doexec. For e.g. if you wanted to link mygrep to egrep, then just:
alias mygrep='doexec mygrep egrep'

While were talking about grep, notice that the functionality
is a subset of sed (or should be). The hard thing to learn is the regular 
expressions (more on these later), so just having to know 1 (sed) interface
would be an advantage. Here's an e.g. of a trivial script using sed to show
how easy it is to add highlighting functionality to "grep":

sedgrep

For backwards compatability as mentioned above, the the grep and sed programs 
should be (links to) the same executable, with slightly different internal 
processing depending on argv[0].

This table illustrates some more possibly redundant commands and alternatives.


 
hexdump
   
od -Ax -tx1z -v
 
 
head
      
sed 10q
 
 
grep expr
 
sed -n /expr/p
 
 
unix2dos
  
sed /$/^M/
 
 
dos2unix
  
tr -d '\r'
 
 
expr
      
is a subset of bc
 
 
expand
    
pr -T -e or sed s/.../.../
 
 
unexpand
  
pr -T -i or sed s/.../.../
 
 
tr
        
could be incorporated in dd
 
 
clear
     
tput clear (etc)
 
 
gunzip
    
gzip -d
 
 
bunzip2
   
bzip2 -d
 
 
basename
  
tr -s '/' | sed -e 's|/$||' | sed -e 's|.*/\([^/]*\)$|\1|'
 
 
dirname
   
tr -s '/' | sed -e 's|/$||' | sed -e 's|/[^/]*$||'
 
 
true
      
exit 0
 
 
false
     
exit 1
 
 
tar -z
    
same as just | gzip
 
 
tar -i
    
same as just | bzip2
 
 
tar -Z
    
same as just | compress
 
 
tar --use-compress-program PROG
 
same as just | PROG
 
 
z{less,more}
 
redundant as less auto handles with lesspipe.sh.
 
Note also apps that need this functionality can use gzopen from zlib, 

or the lesspipe.sh method, so all the z... commands and probably redundant.
 


An e.g. of the above:
    alias hd="od -Ax -tx1z -v"
    hd /etc/fstab
    hd /etc/fstab | ./sedgrep "[0-9][a-f]"

In general in Unix there is not much code reuse (especially server programs) 
probably since there were disparate Unix' until recently and the only common 
denominator usable was libc. This is getting better now with language independent
interfaces to logic like bonobo and mono. Note M$ is way better in this regard.
Note pipes are very useful, but not a silver bullet. For e.g. data flow is
one way only, also there is no type checking, or ways to dynamically determine
what kind of data the sink expects...

Also take the example of the standard text utilities (cut,sort,uniq).
These are inherently record/field based. I.E. they work at a higher level
with the data, rather than a stream of bytes. However they use different
methods to specify fields, field seperators and record seperators (\n,\0,...).
For e.g. uniq can only say skip the first X fields, whereas sort has a powerful
key selection mechanism which would be very useful. Also these could easily
share the same code, making them all simpler and more powerful.
(p.s. I'm currently working on a patch to do this).