Others have pointed out that the premises of the question, that the Bourne Again shell is default and ubiquitous, are downright wrong.
In addition to that, there are indeed good reasons for using something other than the Bourne Again shell for interpreting shell scripts. These reasons motivated Ubuntu's and Debian's big project, over a number of years, to remove bashisms and to make as many of the shell scripts run by system initialization (which was a lot of shell scripts with System 5
rc) and package installation/removal use the Debian Almquist shell instead of the Bourne Again shell.
Simply put: The Bourne Again shell, chock full of interactive features as it is, is not the fastest shell interpreter for a POSIX-conformant shell script. So if one can make one's shell scripts POSIX-conformant, interpreting them with a more lightweight program, like the Debian Almquist shell, one's system will perform better. (In the end, Debian had to make slight adjustments to the Almquist shell, to add support for a couple of non-POSIX shell constructs that were simply too deeply and widely embedded and too useful to get rid of.)
The result of it all was a major gain in bootstrap performance.
So there are two distinct classes of shell to consider, here:
- The shells with all of the flashy interactive features, which are configured as the interactive login shells for users in the accounts database.
- The shells that interpret lots of scripts quickly, which are used as the script interpreters by shell script programs.
Note that talking about this as "preferring
/bin/sh" is oversimplifying. Debian actually had at least two goals:
In the face of administrators using the Debian Almquist shell, the Z Shell (in POSIX mode), the Bourne Again shell (in POSIX mode), the MirBSD Korn shell, and others as
/bin/sh, there was either …
… making the scripts as portable as possible, so that switching what
/bin/sh mapped to didn't break things; or
… making non-portable scripts explicitly target the correct interpreter program, instead of simply expecting that
/bin/sh map to it.
There was making the Debian Almquist shell the default mapping for
/bin/sh instead of the Bourne Shell, so that those scripts that were POSIX-conformant (or, more properly, Debian Policy Manual conformant) ran more quickly.
And of course once one gets into this, one can take it a lot further; such as considering the efficiency tradeoffs of the likes of
/usr/bin/clear being shell scripts or compiled programs. But that's beyond the scope of this answer, fortunately. ☺
None of this is very new, nor even Unix-specific, of course. Back before the turn of the century, I wrote and published a command-line interpreter that came in both "interactive" and "non-interactive" flavours, explaining this very division in its doco and noting the difference between the
OS2_SHELL environment variables. Similarly, discussion of removing bashisms in Debian's System V
rc and package installation/removal scripts dates back to the 1990s.