Well, it'll always take longer to create two zips at the same time than in serial since they are definitely I/O bound operations (assuming your cpu is fast enough) and the two sets of concurrent reads and writes force the disk to seek back and forth between
the two files (this has nothing to do with the fragmentation of those files). But you're right that his solution is not really the correct one, as it makes no sense for the OS to keep the CPU waiting on an I/O operation when it could be executing some other thread that will actually just use the cpu. What might make sense (but you'd have to experiment to be sure I think) would be to try to find a way so that you switched to another thread which wasn't disk bound.
WinRAR is very smart to do this, and it makes sense for it's scenario, but the OS can't enforce this generally, since users expect the system to be responsive, which means programs can't be forced to wait for other programs disk-bound operations to complete
before they can run (or even perform their own disk i/o).
Perhasp Solid-State devices will make all of this moot, since they don't have seek time. It would be interesting to run the zip experiment against a flash drive.
Great demo. While you're right that you can do the service without an async call in the sense that the async call on the user side will prevent the user's UI from blocking, you really still shouldn't use blocking calls on the server side as you're using up
threads on the thread pool and if you have heavy load you'll run into scaling problems.