这个测试并不代表启动过程，但你可以通过编写一个小的测试脚本来自己尝试一下，我称之为
shspeed。
$ cat shspeed
for a in `seq 10000`; do ( :; ); done
这只是简单地连续分叉10000个子shell。现在用bash和dash运行它，并计时：
$ time dash shspeed
dash shspeed 0,70s user 0,33s system 107% cpu 0,965 total
$ time bash shspeed
bash shspeed 1,59s user 0,76s system 108% cpu 2,180 total
所以，在我的硬件上速度要快得多，我的硬件是一台大约1年的Dell XPS 13 9365。你可以想象在低端硬件上会有更大的差异。此外，这个测试只涉及一个for循环和生成一个子shell。也许对于某些测试来说，结果会更加显著。
当然，你可以忽略这一点，并说你不关心生成10000个子shell的速度有多快。嗯，有些人似乎很在意 :)
对于你特定的启动过程，可能不会有任何明显的差异。如果你使用/bin/bash作为/bin/sh，并用秒表测量差异，我认为没有问题。
请查看@wjandrea提供的以下链接，详细解释了这个问题：
https://wiki.ubuntu.com/DashAsBinSh，
What is the point of sh being linked to dash?
在systemd时代的Shell速度
在你修改了问题之后，它听起来更像是你对于哪个shell更快速并不那么感兴趣，而更关注为什么我们仍然坚持让启动过程快上半秒（或者类似的时间），尤其是现在我们不再像sysv-init标准时期那样广泛使用shell脚本。
由于我不参与Ubuntu的政治事务，我会尽力给出一个我认为的答案：
1. 如果通过简单地使用符号链接到另一个shell可以使某个东西快上半秒，那是值得的。
2. 让默认shell只做POSIX要求的事情是有道理的，这样可以保持可移植性。想象一下，一个发行版在初始化脚本中使用了bash的特性，而另一个发行版没有（至少目前没有）。
3. 添加(d)ash也是为了能够修复标准脚本中的bashism，并避免将来出现这种情况。/bin/sh是一个公认的标准，很多大型基础设施都依赖它。我不希望用一个代码库更庞大、功能不必要的东西来替代它。
4. 使用更少的CPU周期和内存总是值得的。即使systemd单位通常在后台运行shell脚本。
所有这些对于普通用户来说可能都是无关紧要的，但间接地，他们得到的是一个更稳定的系统发行版。
为什么不用bash呢？
这更多是个人意见：就我个人而言，我永远不会选择在dash中编写脚本。它只提供了非常基本的结构。对于一个更大的软件项目，我宁愿选择bash或zsh（或者根本不使用shell）。也许我想要使用哪些功能：高级参数展开、shell算术、数组，或许还有其他一些。
这在主要用于启动守护进程或安装软件的脚本中是不应该发生的。这些脚本应该使用最少的指令，并保持可读性和简单性。但是，如果所有bash的好处都能够为它们所用，很可能会发生这种情况。
/bin/sh 应该主要用于在合理便捷的环境中运行外部程序，而不是用于复杂的软件系统。
总结
/bin/sh 作为dash实现的POSIX兼容的快速稳定的脚本语言，在系统的shell脚本中表现出色，成为了标准和默认的解释器。这些特性绝不会为了方便而牺牲。
从程序员的角度来看，它实现了“专一而精”的宗旨。
这不是主要的优化，而是责任分离。
它已经在那里了，所以保持它不需要额外的努力。
从最终用户的角度来看，这引出了一个问题：是什么样的最终用户？桌面用户可能无所谓，但他们仍然会受益于更稳定（也许稍微快一点）的发行版。软件包维护者会非常关心，他们受益于一个可靠的系统解释器，具有一小部分明确定义和经过充分测试的功能。程序员不应该关心，因为他们很可能不在/bin/sh中开发。
附注：bash二进制文件的大小几乎是dash二进制文件的10倍！
/bin/dash的发明是因为当时实际的Bourne shell和Korn shell不是开源的（80年代末90年代初），而且是专有的。 - Sergiy Kolodyazhnyy/bin/dash并不是用于引导启动的，它是用来运行脚本的，并且已经证明它比其他shell更快。 - Sergiy Kolodyazhnyy/bin/sh。Linux 和 Unix 不仅仅局限于桌面或引导过程。 - Sergiy Kolodyazhnyy