Good question. The systems I've done this manually on are one-off builds of 28.x on sandboxed systems where the system emacs is 24.3.  So, I didn't have to worry about managing package updates with any frequency.  

I'm now working on unsandboxed systems where the system version is 27.2 and I've installed 28.x, 29.x and 30.x builds into /use/local.  I don't want to do a manual installation here because I (would like to) regularly update packages with the package menu.   Additionally I discovered that 30.x (and probably 29.x) has introduced a new bytecode instruction, after installing packages under 30.x then trying to run 28.x.  So I've set up my initialization files to use different custom-files, package archive directories, and package-quickstart.el files tied to the major version of emacs that's running.  Running the install through package-install-selected-packages for each version is incredibly slow, but seems the safest way for now.  Hence my interest in implementing a more systematic approach now that doesn't rebuild a massive package-quickstart file for every package installed.

I did file a bug report as a place to hang cpu and memory profiles of the initialization when I loaded everything at startup under 27.2 - see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61004 .  If memory serves, locate-file took something like 75% of the cpu time, and also did an incredible (and dominant) amount of consing. Even if the autoloads in package-quickstart specified a full path for the library (they don't), every "require" of an unloaded system library still has to search the entire 2403 (or however many were in that bug report) package directories first, for every system library required, even if no packages are actually loaded. 

I'm using 28.x as my reference build because re-dumping has been broken under 29.x.

Lynn