My guess is that it's less about performance so much as reliability. I've had three incidents in the last two years which required connecting to a server that had an out of control process pool that had exhausted pids.

I also had a storage controller go and had to figure out how to use shell builtins to create a tmpfs and reflash the firmware.

There are many reasons to provide builtins for basic file commands, from saving the extra process start to the tiny performance boost for scripts that should probably be using find instead.

The built-in replacements run in the same process as the Bash shell, and thus, avoid the fork/exec system calls.

It's a minor performance optimization that might be useful if you're doing thousands of rm's or stat's in a script.

It seems like this would eliminate the need to read a file from disk and fork a new process, both of which take time. If you're just removing a single file, this is probably negligible, but if you have a script iterating over 10k files, i.e., this speed-up may be more welcome.

It’s faster to run them as a builtin than to exec the external binary. It makes a big difference when looping over many items.