Consider this example:
for i in $(seq 1 10); do
for f in /*; do
if [ $f = /etc ]; then
: # Do nothing.
fi
done
done
I have 23 entries in /, so this will run [ 230 times – not a crazy number. % time sh test
sh test 0.00s user 0.01s system 91% cpu 0.009 total
bash, dash, zsh: they all have roughly the same performance: "fast enough to be practically instantaneous".But if I replace [ with /bin/[:
% time sh test
sh test 0.11s user 0.38s system 96% cpu 0.509 total
Half a second! That's tons slower! And you can keep "fast enough to be practically instantaneous" for thousands of files with the built-in [, whereas it will take many seconds with /bin/[.(Aside: if I statically link [ it's about 0.4 seconds).
Of course if the script were to handle all files of a filesystem with many small files it could get disturbingly slow. I don't deny that there are cases were it matters. But in over 90% of the scripts I write or use it doesn't.
It's up to you whether half a second is "fast enough" (just an example: can easily also be 2 seconds, or 5 seconds), but it's definitely a lot slower than 9ms and not "only much faster in theory", or "unnoticeable in practice", and "number crunching" doesn't come in to play regardless.
Since the cost of this optimisation is minimal (you can just use the source of /bin/[ as a builtin) I don't see why anyone would choose half a second over 9ms.