The patterns are really the crux of the problem. Design patterns are an excellent tool, but applying the same design pattern to every problem doesn't make sense. They need to be selected to match the problem. That's where the frameworks go wrong. At least the ones I've seen attempt to wedge everything an MVC pattern on the server side, which really leads to a lot of confusion (and enough misunderstanding of what MVC means that the term no longer means anything).
If you can really use the Zend libraries without pulling in all the other cruft than that's great. Choose them if they suit the task. Then you're really just doing what I suggested to begin with - selecting the best libraries for the job. (My impression was that this wasn't possible, but I didn't dig very deeply into Zend - by the time I looked at it I'd already developed a deep hatred of frameworks.)
Apache is generic knowledge in that you can apply it to a wider range of problems, and since every installation needs a web server, it's not something "extra". You have the tool already - learn to use it. Same with Nginx or one of the SQL servers. Every component you add has a cost in maintenance and complexity, so don't add more components until you've fully exploited the existing ones.
My main complaint with frameworks isn't efficiency. But you have touched on another problem. I know one poor sucker whose life is now devoted to trying to optimize an all-php solution, when a few weeks of investment in a Jave or C component would speed up his application 100-fold. Alas, try convincing a project manager that you need to invest a few weeks optimizing without producing any new features. He'll be stuck tuning that app and trying to squeeze performance out of Memcache until he burns out.