What do you like best?
There are plenty of well written, documented and supported Chef recipes for dealing with all sorts of server automation, like users management, database management, Solr configuration, full application stack configuration (Sensu, Gitorious, Redmine), SSH, and many more commonly used software. All of them are open-source and have plenty of customization options. Chef itself has good documentation.
Dependencies management is very easy and robust by using librarian-chef.
Chef's verbose mode is very helpful when debugging what a recipe is doing and there's also a dry runner mode which won't actually run anything in the server, which is also helpful in some cases.
Unlike Puppet there's no domain specific language to learn, which is a big advantage for me. You only have to learn a bit of Ruby, which is an easy language to learn and use and you are able to perform any logic pretty easily when compared with Puppet which is quite limiting when you need some custom logic which is not handled by their DSL and you are forced to extend their DSL.
Chef can be configured through an specialized server that will orchestrate all managed servers or they can be used without setting up any Chef server, through chef-solo. Chef-solo can be integrated with Vagrant as well to help setting up a development environment very quickly.
What do you dislike?
I'd prefer Chef's focused on chef-solo for most of its beginning tutorials as I find it the easier mode to start with and also the most useful one for most small organizations. The fact that chef-solo is not the tutorials assume makes it harder for a beginner to understand how it works.
I also think they could be more backwards compatible in new releases. I remember it took me quite a while to fix some old recipes I had so that it would work in newer Chef releases...
They use JIRA to manage their tickets and I really don't like JIRA.
Recommendations to others considering the product:
I'd recommend starting with the chef-solo mode, which is much easier to start with and well suitable even for more complex servers infra-structure. Also, take some time to learn some Ruby if you are not comfortable with the language.
What problems are you solving with the product? What benefits have you realized?
We integrate Chef and Capistrano to manage our servers and deploy our applications. Since both are written in Ruby, we can share a dynamic configuration written as a Ruby DSL that is used by both Chef recipes and Capistrano tasks. We use Capistrano to run Chef in the servers requiring changes.
For example, we manage multiple environments and applications in a shared set of servers. We have a database server and two application servers and we are able to properly manage the database in the database server through Chef, configure Solr, install packages in the application servers, set up nginx in the right server and everything that is required for the application to run and finally run the deploy procedure using Capistrano tasks, which are more well suited to handle deploys and rollbacks than Chef is. The server management part is handled by Capistrano running chef-solo in the right servers. Then the deploy proceeds as usual with regular Capistrano tasks. All with a single command line that will inform the application, which application server to deploy to and the environment (production, Cert, experimental, staging and others).
Being able to run a single command to handle the full deployment cycle gives a lot confidence specially because there are lots of steps involved for our applications to be properly configured and run in our servers... It would be really easy to forget some of those steps in a big release without the automated recipes.