It's probably the XML.

Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.

I honestly have not a single clue about Puppet or Chef, but the company I work for uses bcfg2. All of the SAs hate it with a passion. We have written so much code around it to make it usable that it could probably compare with amount of code in bcfg2 (well not really, but it's a lot).

Main reasons for me:

Client-server model

Insufficient online documentation for what seems to be a verbose and somewhat limited configuration language.

The XML is a minor turnoff but for me it's more a question of what the language is doing. Eg:

        <Package name='openssh-client'/>
        <Package name='openssh-server'/>
        <Package name='emacs'/>
        <Package name='curl'/>
        <Package name='rsync'/>

In puppet, you define a list of packages and then install them with one declaration or do any number of other things with that same list.

bcfg2 works well. It aims toward 100% fully managed servers (i.e. package dependency management, full /etc management) more than Chef/Puppet (but other than DoD/banking, 100% management isn't worth it). Other reasons I prefer Chef are 1) solo mode, 2) more dynamic recipes with ruby 3) more out-of-the-box resources (dirs, files, templates, users, etc)