If we find that having them in individual files is too slow (which I don't believe will be the case, but is something we have to benchmark, not go either way on just because of a gut feeling!) we can develop a caching layer to handle this.
Optimise later, I would say. And benchmarks in this case are going to be really weird. Too many different filesystems with different penalties, with or without caching, file or db cache, with or without opcaches, .... IMO, this is exactly a case to try and make the best possible case for the designers. I think big files are bad, because it is hard to grasp them easily at once. For the theme_ to be separate from the main code is better, since you usually need those during design, and don't need to go through vast amounts of unneeded for the task code. Especially if you are not that familiar with php. I vote to make life easier for the designers. And optimise the performance later. I think it is quite doable. I've done a rough split of the theme functions from the modules based on the current 4.7 (didn't have the latest cvs, but it should be similar). If you want I can prepare a patch and submit it on drupal.org together with the split code (slow, ugly, but quick to code).