To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself.
However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.o...
Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.
Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life.
As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.