The way I explain this to people is as follows:
The reason for acs-objects in the first place was to implement a psuedo-OO layer on ACS. The benifits (not all realized for sure) included, a single location to add functionality (i.e. audit trails), since an object can only exist once, tracing to the parent is possible (this is the reason that the ip/date/ etc are stored in the base object, usually acs_object directly, CR is a seperate case).
That said it is obvious that not all data should be acs_objects. I think that most of this "bad" coding was the legacy of AD personnel writing packages before the kernel was stable and certainly before any best practices were in place. The exercise at the time was to release the "new" ACS4 with most packages in place.
If you look at the way I wrote acs-reference et al, I think you will find a good use of the acs_object system. The reference data is not stored in acs_objects only the fact that the data exists is an object.
I completely agree that many packages went overboard and all tables are stored as acs_objects. Bboard is a problem but I don't think it is possible to fix this easily (i.e. it is better to write it from scratch). I also can see some reason for all messages being acs_objects but that is because the data model wasn't thought through to eliminate that dependence. One reason for using acs_objects is to get the permissioning system for free and I believe that was the major reason, that and the fact that bboard was the 2nd or 3rd package ported from 3.x.
I for one really think that a best practices doc should be written to solve some of these inconsitencies but alas most of us don't really have time. In the meantime I think peer review of any new package is the best bet, especially since we are now "db independent".
