Since the transfer is over USB2 and the eMMC itself has write speed limits I am unsure about which part is the biggest bottleneck. Knowing may not help much, but there is one thing I can think of which might work in a production environment if it turns out that the USB side is the limit…
You could create a base bootable minimal image which flashes quickly, boot up, and then use gigabit network to rsync your edits in. A 12GB update would no doubt take a lot of time, but it is conceivable that rsync (which compresses) over gigabit (probably faster than USB2) could speed things up considerably.
Note that if a base image is set up with specific ssh keys and if the base image unlocks the root account to ssh (normal login would not need to be unlocked), then rsync easily becomes a productive way of updating. The rsync itself could even disable the temporary root unlock. The procedure as a whole is not actually difficult, but there are a lot of steps I’d need to explain in detail…let me know if you want to try this. Before starting what you’d want to do is create a copy of your current clone image, cut out whatever packages you can think of to make this a good starting point (such as kernel version and dtb matching your production device, but skipping CUDA and other optional packages). We could take that starting point, set up ssh keys, set up root ssh unlock, clone this, and then set up a batch file system for rsync to copy from your final clone under loopback to the JTK1.
There is no guarantee this would actually be faster, it could be a waste of time…but I think the odds are good enough that you may find it worthwhile to at least test.
And actually there is one more similar option where you start with the fast cut down version of your clone and rsync…the Jetson itself could run rsync over a SATA connected hard drive and skip all of the ssh and gigabit connection (rsync could be perfected this way even if you intend to eventually go with gigabit). This would require a hard drive for each rsync, whereas a single rsync server over ethernet would work with a lot of TK1s updating all at the same time (an rsync server has a speed advantage when reading a single read-only file system over and over because of caching…caching and running over ethernet has the potential to be faster than a directly connected drive because access is actually from RAM after the first read).