Ask me which framework to use and I'll probably have a grumpy old woman moment and tell you that all frameworks are as bad as one another. Which is not to say they are all bad, exactly, but in PHP we have an unimaginably large number of frameworks (usually cited as N+1, where N is the number of PHP developers in the world), and they all probably made sense to the person that invented them.
Having a choice of frameworks is probably better than trying to use only one framework, regardless of what exactly you were trying to build, because it's the 'best' one (by whatever measure of 'best'). This selection of framework offerings means that you can pick something that meets the needs of the project and it might even be documented. Frameworks on any platform are really there to provide structure, reusable modules and libraries, and generally avoid all the boring and repetitive tasks to do with building the same functionality over and over. For example when building CMSes, something should process and validate form fields for me; if left to my own devices I may miss out something important and I'd much rather do the elements of each project that are different, rather than the ones that are the same every time!
Full-stack frameworks
Full-stack frameworks, such as Zend Framework, can be a nice place to start for a developer without a lot of architecture experience. It gives good structure to hang a new application on, and there is a good 'ecosystem' around it – plenty of books, tutorials, and some reasonable documentation too. If you are trying to build a large application which will be maintained by a lot of people, then a popular, comprehensive framework is likely to be a good choice as it will dictate quite a lot of structure and be well known and understood.
Having structure to help with separation is always good; early on in my career I worked with some very junior developers and attempted to teach them the MVC (Model View Controller) pattern, which was relatively new at the time. We made the decision to use Smarty in the view layer; partly so that the designers could work with the templates more easily, and partly so that when someone came to my desk and said "how do I do X with Smarty?" I could say "don't do X in the view!" (nine times out of 10, that was the answer). Having frameworks helps us to find the same separation in other parts of our application. Many of them do support integrating against a templating layer such as Smarty, or my new favourite, Twig, so you can take those tools with you whichever framework you choose.
Lighten the load
There are plenty of lighter frameworks than Zend Framework, for example I work with CodeIgniter quite a bit. Is it as comprehensive and robust as Zend Framework? No, it isn't. But as a helper framework to enable building an application rapidly, it's useful. In general, frameworks with less 'helper' functionality can be easier to find your way around as it's much more obvious how the pieces go together. In an unfamiliar framework (for me, that's pretty much everything), it's the automagical bits that make it hard to work with and debug.
That feeling of being "lost in a new framework" is unavoidable and utterly frustrating; even an experienced developer feels like a newbie when they don't know how anything works. If you're really unlucky, you'll have picked a framework whose IRC channel will tell you that you're an idiot as well! It's this very negative initial experience that puts a lot of people off using a new framework or adopting one in the first place, and very few frameworks do a good job of helping new users over that initial hurdle.
In PHP we also have some frameworks that aren't really frameworks in the way that I usually use the word. We have some lovely component frameworks; collections of libraries designed to be use-at-will and to play nicely together, such as Zeta Components (previously eZ Components) and Symfony Components (have you seen their site? They win the award for best artwork!). The best and most undersung of these is, of course, PHP's own PEAR and PECL offerings – somehow these get forgotten in this brave new world of frameworks.
Microframeworks
Microframeworks are an emerging trend in PHP; these are super-lightweight offerings that just help you to glue things together more quickly. A good example is Slim, which is very fast and simple to use, and understands RESTful concepts. It is based around the idea of 'routes', which are URL patterns. You register a route and give a callback which should be invoked when that URL is requested.
Most PHP developers adopt a framework and stick with it, or they might use one at work and another for their hobby or open source projects. There is little consensus about the "best" framework to use so everyone just sticks to what they know and the result is parallel development of massive numbers of frameworks! I love to have a selection to choose from, but did I mention that they are all just as bad as one another?
If you know Zend Framework then you end up describing yourself as a Zend Framework developer; you wouldn't be comfortable writing in another framework until you'd had a chance to get to grips with it, and you probably don't remember many of the raw PHP functions for things if you don't use them often. This idea that we've become framework-specific developers, only working on top of layers of abstraction, is a bit strange for PHP. After all, this is the language "to solve the web problem". It's written in C and is a fast, light language in itself ... providing you don't wait for a large framework bootstrap process to run! From this context emerged the MicroPHP Manifesto, written by a man we call Funkatron (although his name is really Ed Finkler). It's a series of statements saying that it's okay to build a number of interoperable small modules, that bigger is not better, and that really, life is too short for Java – even if it is written in PHP.
