When upload-artifact is provided an existing zip file via its path: argument:

        with:
          name: asset-package
          path: asset-package.zip

It double-zips the zip, resulting a zip within a zip.

"You're using it wrong, don't provide a zip file!", might be a counter-argument, however zips might be preferred because:

• Some off-the-shelf workflows automatically produce a zipped result, therefore it would make sense to take it as-is.
• Re-zipping needlessly burns CPU, always results in a larger file, wastes user time, confuses users, and adds complexity to down-stream automation.
• Providing a zip can be faster than uploading a directory of files because it avoids the per-file latency multiplier that (possibly thousands of) individual transfers incur.

"We can't trust your zipfile; what if it's some other file in disguise!", could be another argument:

• Ok.. but the asset zipper already trusts any file anyway; so security already isn't a concern. People could already be feeding the assert zipper viruses and trojans for all we know.
• If this is a concern, a content/type check could be applied to confirm the file is a bonafide zip. If you still don't trust it, then the zip could be decompressed to /dev/null and confirmed good, as opposed to double-zipping the zip.

Yes, a work-around would be to unzip our resulting zip to a temporary directory, and then provide that to the asset uploader - however we're now wasting three rounds of zipping: initial zip, unzip, re-zip.

GitHub already gives developers full control over the content that they're uploading, so using a zipfile straight-away is just another means to provide the same content without a second layer of packaging.