Based on our hallway pow-wow at PyCon 2015 sprints day #1...  I audited the zipfile module to confirm our suspicions about it being "large".

In current Python 3.5 head's zipfile.py module here are the things it depends directly upon from other modules:

import io  # [Py(C: _io)] io.BufferedIOBase{,readline}, io.BytesIO, io.open
import os  # [Py(C: various)] os.path.*, os.getcwd, os.stat, os.listdir, curdir, pardir, 
import re  # [Py(C: sre_*)] Only used for universal newlines in ZipExtFile.readline().  Shouldn't the io module do this part for us?!?
import importlib.util  # [Py] importib.util.cache_from_source() from PyZipFile to create importable .zip files.
import sys  # [C] sys.platform for creation metadata, sys.stderr for a strange print on a DeprecationWarning.
import time  # [C] time.localtime, time.time
import stat  # [Py] stat.filemode, stst.S_ISDIR
import shutil  # [Py] shutil.copyfileobj() from _extract_member().
import struct  # [Py(C: _struct)] struct.pack(), struct.unpack(), struct.calcsize()
import binascii  # [C] binascii.crc32() only if zlib is unavailable. (store only zip support?)
import threading  # [Py] threading.RLock() in ZipFile.

import zlib, bz2, lzma are all conditional.  # [C]

import warnings  # [Py] conditional import to highlight legacy uses.
import py_compile  # [Py] conditional import in PyZipFile for importable .zip file creation.

Some of these are obviously shims around C extensions which could conditionally be used directly if desired.  But many others are largely implemented in Python.  Freezing all of these just to use the bloated zipfile.py within a pure Python zipimport implementation seems like extreme overkill.  Not worth the effort.

Efforts for improved zipimport are now likely to focus on a simple C zip file reading-only library being used by a new clean implementation of a zip importer on top of that.