In addition, using simple hashes and arrays makes it much simpler for your average software engineer to make changes they want - they have to learn little to no Chef in the simple case... even not knowing ruby they can figure out variable assignments.
The monolithic repo works well for us given we use grocery-delivery (github.com/facebook/grocery-delivery). We have no environments (see my ChefConf keynote in 2013 for a full breakdown of how we do run things) and no cookbook versioning... we run directly off of head. We use a combination of taste-tester (github.com/facebook/taste-tester) for general testing and and sharding (see `node.in_shard?` and `node.in_flexible_shard?` in the `fb_helpers` cookbook) to control the speed of rollout of risky changes.
To be clear we use no precedences at all except `default` - using other precedences will in fact likely break our model since it causes the node-read code to merge things rather than treating it like a single hash. The model here is last-writer-wins always.
As for tests, people consuming these cookbooks are simply assigning variables, so there's not a lot to test in a wrapper cookbook. "Did the attribute get the value I assigned it" doesn't seem like a useful unittest... that should be covered by Chef's unittests itself. For our more complicated cookbooks we've unit-tested the API and where we could we released those (see fb_fstab), and we have some other unittests we haven't yet been able to release that hopefully we'll come back around to.
Hope that helps, - Phil