The actual time to import a library is roughly the same regardless of doing it at instance startup time or on-demand, inlined inside a particular request needing it. Similarly, the memory footprint of the library is the same once loaded.
So, for the request actually needing the library - it doesn't really matter.
But for the other requests, it may matter, possibly a lot.
Blindly loading all possibly needed libraries at instance startup time means the instance will start slower and will use more memory than if loading only the libraries necessary for the request that triggered the instance starting. But once the instance is started all subsequent requests will benefit from the minimum response time - no additional code needs to be loaded, while in the other case the response time for some subsequent requests will be increased by the time required to import the libraries not yet imported (once per library per instance lifetime).
Some will consider apps importing all libraries at startup more costly, slower to start and bulkier than their on-demand importing counterparts. Others will see them as more deterministic in performance, which may matter for some apps.
On-demand importing libraries, especially rarely-used hefty ones, offers a unique advantage: the app can (at least partially or in degraded mode) run even if the total memory footprint of all libs exceeds the memory limit of the instance type - which would be impossible if attempting to load all the libs at instance startup time.
A variation of on-demand importing is lazy-loading of entire files containing request handler code, see App Engine: Few big scripts or many small ones? An actual example is here: What determines start up time of dynamic instance and can it vary between weeks if code is same)