My response echo's a little of what Mike said... a lot of site collections stay pretty small, in which case it is much more efficient to keep them in a single content database so that there's not as much overhead (more about the number of objects in the instance than a performance perspective) in SQL Server associated with them from a database perspective.
To me, this is a governance issue. I create three site collection quota templates in most environments, 1 GB, 2 GB, and 5 GB. Everything starts at 1 GB unless the site owners make a case otherwise. A bump from 1 GB to 2 GB is free, mainly its there as a checkpoint for the farm admins to ID sites that are growing quickly and as incentive to owners to clean up their sites. 2 GB to 5 GB requires approval (although who approves can vary), and at this point I want farm admins to start taking a closer look at the site, understanding what's going into it, and determining if it needs to be in its own content db or not. When the 5 GB template is used, the site should go into its own content db.
Microsoft has some specific capacity recommendations and limits tied to site collection size, content db size, and the number of content dbs attached to a given web application. These numbers vary depending on if we're talking about SharePoint 2007 or 2010, I would recommend looking at the TechNet capacity planning centers for each product for much more information on that:
In general, I would rather start with three content databases with the purpose of distributing site collections across all three, and then create individual ones for site collections that I either know will be large right up front or identify themselves through the governance process outlined above.