I understand... the way the download Zip Servlet works is by creating a zip stream to which it starts writing all files (images) from the study. It first performs a query against the database to obtain all paths from the files, and then reads them and writes them to the stream. It basically creates the Zip file "on the fly" if you will, so what you are seeing is not related to the download speed and has more to do with the processing power and read speed on the server's hard drive.
So, for a study that contains a large amount of images the bottleneck is really the 2K+ disk reads that it needs to perform... you are not downloading a single existing zip file of X size, the server is actually reading all images and creating a zip file "in real time".
Can you do the following test please: From a workstation, try to time how long it takes you to download a large study using a DICOM query/retrieve command, and I mean to download the whole thing: all 2K images, and then try to time how long it takes to download the same study as a Zip file from the GUI on the same machine.
Concentrate on how long it actually takes to download each complete study, not the stated speed.
In my experience, specially over the Internet, for large studies, the Zip file even though it is created in real time has always been faster, but your case may be different, if it is actually taking WAY longer to download the Zip file then something is going on with your installation.