Dude, no... Please, just take a few minutes/hours and learn how things are done. There is no excuse for the ridiculous file sizes. Just learn how to properly utilize assets and optimize maps. A little effort goes a long way in that respect.
Let's take your Duke 3D map for instance. The BSP alone is 320MB (I'm using base-10 here because that's what my file manager uses). Even BZ2-compressing it would give you a big improvement for free (you literally don't have to do anything else). That would cut the download size from 320MB down to 60MB instantly. But nonetheless, let's compare this file size to some other items.
Chateau DuClare, which is a fairly large map incorporating custom sounds, textures and models, is 66MB uncompressed. Your retro-themed, low-res map is almost 5x bigger than a modern map. Better yet, your one BSP alone is 25x bigger than the game it came from!
Now let's take a look at the files inside your BSP... You have several lengthy WAV files that may have been better-suited for other formats, or maybe even their quality cut down without audible loss, especially since the offending WAVs (the arcades ones) are a small detail and are barely audible. They account for a relatively small, but still considerable, amount of the BSP. Your sounds folder (again, only what's in the BSP, not including music) is 38MB.
/models is 6MB, not bad, but still, you included editor assets and the GE:S ammo crate, a rookie mistake that only happens if you "select all" in Pakrat.
/materials is where things get interesting. This folder is 270MB. You included tool textures here, again a rookie mistake, but that doesn't even register on the file size. The worst offenders are 4K textures for what are small surfaces in the map -- again, the arcade machines. Not only that, you have a few super-high-res, detailed textures, in a dimly lit area of the map where they go unnoticed. Not only that, but they're mixed in with super low-res arcade machines. If you kept it consistent with the retro aesthetic of the map, or even stayed conscious of how these assets are used and chose/adjusted them properly, you could have shrunk the size tremendously. The Pac-Man arcade has 2 textures of 22MB, one of which is solid black.
You also have multiple lengthy animated textures, that range from 20 to 72 MB. PER. TEXTURE. You could have gone with simpler, shorter animations or done away with it entirely, inflating your map size so much is not worth it for an easter egg.
And keep in mind, all these textures have to be loaded into memory. The engine has a memory budget, and abusing it like this is why some of your maps crash so often.
Not only that, but your map has TWELVE music tracks! And ALL OF THEM ARE UNCOMPRESSED WAVS! 20 - 70M EACH and add a combined 550 MEGABYTES to the map!
And that's before we even get into map optimization techniques. Properly sealing leaks, using nodraw on hidden surfaces, among other things, will help tremendously on file size, compile time and in-game performance, which has long been a problem on your maps. But it won't help with size as much as say, not using uncompressed WAVs at every opportunity.
If you learned how to properly optimize your maps, you would find everyone would download much faster, the performance would be better, and your problems would go away.
Like, sorry dude, but we've tried over and over again to try to help you course-correct but you just won't take the hint. Get better instead of deflecting criticism. Sheesh.