MKV is the container… which video codec is being used?
I ask because depending on the answer, it might be possible to get the benefits you want without the overhead and incompatibility of a zip file.
As I’m sure you already know, zip compression is lossless. Compressed files can be perfectly reconstructed. In the video world, this roughly equates to the lossless video codecs.
So my curiosity is whether converting your videos to lossless Ut Video format would provide compression ratios and speeds that were on par with a Zip file. After all, Ut Video and Zip formats are both based on Huffman encoding. I would expect close-enough file sizes due to their common ancestry. (This is of course assuming your source video format has basically no compression. Zip format may show a slight lead because it isn’t limited to frame boundaries like Ut Video is. But that lead may be insignificant.)
If this turns out to be true, then the Zip format could be entirely skipped, and you could go direct to Ut Video, which is a true first-class video format that is immediately usable by Shotcut. This would also give you the ability to preview videos in VLC without having to unpack them, which could be great for locating the archived footage you need in a project.
Batch conversion to Ut Video can be done with ffmpeg, which in essence would replace the pkzip command:
ffmpeg -i MassiveStreamedVideoFile.mkv -c:v utvideo -pred median -c:a copy HopefullyLessMassiveVideoFile.mkv
The -pred median part can provide some increased compression efficiency at the slight cost of speed. The default is -pred left which is really fast, perhaps as fast as pkzip.
Also, there’s the option to change the pixel format if desired by adding one of these flags before the -c:v part:
-pix_fmt yuv444p
-pix_fmt yuv422p
-pix_fmt yuv420p
These are ordered from largest file size to lowest file size. If your source files happen to be RGB or YUV444, you could save even more space here by converting to YUV422. The quality difference would not be noticed since Shotcut edits in YUV422 anyway (assuming you aren’t overriding it to operate in RGB mode, which would provide no benefit since YouTube will pull RGB down to YUV420 anyway).
For even more compression, there is the option of using libx264 in lossless mode with a GOP of 30 or higher. The -g parameter sets the GOP. For streaming video games, 60 or higher may be ideal. libx264 might (or might not) take slightly longer to convert, but the space savings could be drastic:
ffmpeg -i MassiveStreamedVideoFile.mkv -c:v libx264 -qp 0 -g 60 -b 0 -preset ultrafast -movflags +faststart -c:a copy StunninglyTinyVideoFile.mkv
The -pix_fmt flags apply here too, if the source was RGB/YUV444 and you want to drop to YUV422 or YUV420.
The whole “can find stuff first with VLC” benefit applies to libx264 as well. Actually, I’d recommend trying the libx264 option first over Ut Video, now that I think about the space savings. I’m just too lazy to rewrite everything I already wrote. 
I’ve gone down the lossless video rabbit hole because a Zip file provides lossless quality, and I wanted to provide an equivalent solution. But if you don’t actually need lossless and are content with “good enough”, then libx264 can go really fast with huge space savings if allowed to work in veryfast mode:
ffmpeg -i MassiveStreamedVideoFile.mkv -c:v libx264 -crf 16 -g 240 -b 0 -preset veryfast -movflags +faststart -c:a copy OhWowItsSoTiny.mkv
Real-time video editing would probably not be possible in this format because the reading and decoding phase has too much latency.