Well ... we want to see content in the content repository so we can have a centralized facility for managing permissions on content, relationships between content items, auditing of content changes, a single UI for adding and modifying content, etc.
And the CR is built upon acs objects.
Workflow and permissions both work on objects, and any kind of categorization or other "knowledge management"-type feature we build will operate on objects as well.
So in short any information in the system that is meant to be used in a general way should be an object. Only items that are tightly controlled within an application and that aren't meant to be exposed to other packages (search being another example) should be non-object tables.
It is possible to go overboard with both objects and the CR, of course. But careful use of the object model shouldn't be overly expensive. Big tables themselves aren't really much of a problem, RDBMS's are designed to handle them efficiently. The permisssions model is a much more significant issue in terms of performance.
Now ... the object model includes a generalized attributes model that lets you define and store data in a single attributes table through an API. The attributes model is fairly expensive and I suspect the quote you've posted is really meant to mean that you shouldn't be using the attributes feature of the object model for large scale application data storage, but should rather be using a separate table. The object model allows for extension by mapping a type-specific table and indeed that's what is most commonly done.
We do need a best practices-type document and we do need to take a careful look at how the object system is used. Bboard's a bad example, unfortunately. There are other bad examples, too.
