The actual documentation is quite interesting:

A ZIP archive appears to be a database containing a single table with the following schema:

    CREATE TABLE zip(
      name,     -- Name of the file
      mode,     -- Unix-style file permissions
      mtime,    -- Timestamp, seconds since 1970
      sz,       -- File size after decompression
      rawdata,  -- Raw compressed file data
      data,     -- Uncompressed file content
      method    -- ZIP compression method code
    );

So, for example, if you wanted to see the compression efficiency (expressed as the size of the compressed content relative to the original uncompressed file size) for all files in the ZIP archive, sorted from most compressed to least compressed, you could run a query like this:

    sqlite> SELECT name, (100.0*length(rawdata))/sz FROM zip ORDER BY 2;

Or using file I/O functions, you can extract elements of the ZIP archive:

    sqlite> SELECT writefile(name,content) FROM zip WHERE name LIKE 'docProps/%';

https://sqlite.org/cli.html#zipdb

Zip support shows up in a lot of places you wouldn't expect, in a way that doesn’t happen with other archive formats. Like python letting you import classes from one.

That's setting aside the number of file formats that are themselves just zip files. e.g. jar, xlsx

Not sure I’d ever want to use zip. Sqlar is nice though.

https://sqlite.org/sqlar/doc/trunk/README.md

Sounds like feature creep. Zip is not a database, at best its just slow. Use a archive utility to handle archives.