It appears that external objects (specifically, image files placed on the various pages) are not actually read until the pdf->save() call at the end.
I think PDF::Reuse was designed for fast pdf generation with data consumed as they come and pdf parts/portions written (and data disposed) as soon as they are ready. My impression from reading PDF::API2 sources was it also had that goal to write/forget parts no longer required, but it wasn't implemented in earnest. If your concern is that "a very few gigabytes" file would be kept in memory until finally saved -- then yes, it would (i.e. if you succeed).
If, OTOH, the only issue is with 10000 temp files scattered around -- it's only true for jpeg images, which are imported using their filenames. See this line and thereabouts. The private ' streamfile' key is nowhere to be found in modules to import other image formats. Reading same source file, pass a filehandle instead of filename, but note (line 42) tiny 512 bytes buffer as opposed to 4096 bytes, which would be used in your original test when all jpeg files are read "at the end".
Without SSCCE, I can't comment on GD being that much slow, but I'm surprised "decode jpeg -- scale -- encode jpeg (and that into memory, not disk file!)" can be be 100 times faster/slower.