Is performing the runtime fire drill of assembling myriad program fragments, hoping they still fit, so you can have the illusion of tiny executables an anachronistic sub-optimization?

If having "the illusion of tiny executables" was the only reason, or a primary reason, (or even a good reason) for using dynamically linked libraries, it probably would be anachronistic; but since it it isn't, it isn't.

Dynamic linking allows perl to use any one of, and any combination of, thousands of cpan modules that contain one (or more) XS (C/C++/Fortran/whatever) components, without the user having to recompile their perl executable (and resolve all the conflicts, duplicate dependencies and idiocies), every time they want to added a new package to their installation.

The alternatives to dynamic linking are:

• Your perl executable is huge, because it is statically linked to the (35/40%?) of the 131,312 packages on CPAN that have XS components.

  Even though you may never use 99% of them.

• Every user re-compiles their perl executable -- having resolved all the conflicts, dependencies and idiocies -- every time they want to add a new module to their installation.
• Every user has a few hundred or thousand different perl executables on their system.

  Each statically linked to all of the libraries required by a particular application, script or one liner.

I have read that there is roughly a 10%-30% performance penalty for shared Perl vs static.

News: Not everything you read on the internet is true.