Our experience working with many clients is strongly pro-monolithic, to a point:
I draw a distinction between general wrapper cookbooks and specific logic cookbooks. I've seen myriad names for both these ideas, here's the difference:
General cookbooks: These are typically wrappers that provide a standard, within your org, means of doing something. If you regularly deployed LAMP stacks, this might be a cookbook that pulls in Apache, MySQL, and PHP, setting them up your standard fashion. Similarly, if you had a suite of security mandated things that apply everywhere, you could have a single cookbook that delivers the same setup everywhere. These are essentially "dumb" cookbooks, that do the same thing everywhere.
Each of these make sense in their own repos, because they do not have interdependencies with other cookbooks you manage. They should be independently testable, and essentially provide known, org-specific service installations/configurations. They would generally not deploy any application code, but rather prepare a system for the application deployment.
Specific cookbooks: These are cookbooks that tie things together, and deliver application "aware" configuration logic. Here you might find "role cookbooks", or other approaches to deliver fairly granular configuration to your deployments. Another example might be a monitoring cookbook that has distinct recipes that correspond to different applications or services.
These go in a monolithic repo, because each one has little-to-no meaning outside of the collective. This repo also holds data bags, roles, and environments. It is the only repo that uploads directly to the Chef Server. This keeps your ultimate concerns (the application and service deployment and configuration) all together, while allowing you to offload as many general items to cookbooks that are then treated as upstream dependencies.
Michael