Another reason for such a dance is my own approach to bootstrap lightweight Perl+Tcl::Tk, much like PAR but without temporaries and with on-the-fly in-memory unzippings, where my first module (Tcl.pm) will not see anything, because perl library forest is not established yet.

I'm guessing the chances you can get a perl process that has no Exporter.pm are zero to nil. I don't think your avoidance of Carp on the principle of also avoiding Exporter is sound.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

yes, Exporter in unavoidable.

But, let me repeat my point, I have some bootstrap technique, and during first stage of bootstrapping no Exporter and Carp are available, so I must strip them out from Tcl.pm, which aims bootstrap.

The problem is that the patch to load Carp lazily actually added more code to the core than if the author had left well enough alone. Carp itself is tiny.

... but your version always will read Carp.pm from disk, even when its not needed.

We can discuss whether this optimization is premature or not, but sometimes avoiding Carp could be explained... somehow.

Another example - when using DynaLoader elder Perl may times checked for $^O, like it could change during the run.

There are Yin and Yang - some people stuck unneeded modules everywhere for the sake of imaginary improvement of code readability, others send optimization patches, because otherwise using innocent module will result in some tens of unneeded PMs loaded.
It seems to me that if Ilya Zakharevich never send his optimization patches, then Perl could be as slow as Java...