Thanks for your reply. Yes, the ready availability of the code would be a plus. In my mind utilities like grep or sort are very sensitive in terms of performance, but that's just an impression.
One could hope that with many of these utils they're mostly IO bound, and so a scripting language wouldn't change that much. I know at one point I actually had a python based md5sum that was faster than the regular gnu one for big files - as it loaded the data off the disk in huge chunks.
I believe ack-grep was written in perl? And that's pretty fast.
Also - how fast does it Actually need to be? It's not high-frequency-trading or a 60fps game... A computer these days can probably load perl, run a script, and display the output faster than a computer from 20 years ago could run the original c util... And if everything is written in it, then a lot will be already in memory. If your shell is written in it too, then you could just call the utils from within there, rather than having to fork/exec it anyway.
For most higher level scripting languages (such as perl, python, ruby, etc). Things like regexps and hash tables are written in c underneath anyway.
With a lot of shell scripting, you call many many utils many times - which would slow everything down hugely if you needed the scripting language startup costs each time. However, if you use the same higher-level scripting language to write all your scripts in - rather than writing SH scripts that call your utilities, then you might even get faster than SH calling external utils (possibly). (If that makes sense...)