I think the sentence should be removed also. I remember reading it, taking it at face value and putting creation dates in other tables. Now I just join against it and I don't see any problems.
I'd also like to see context_id and inherit_p gone also. They just take up space and replacing them with parent_id would also solve the problem of using context_id as a parent_id. I'd also like to see object_type replaced by object_type_id. The varchar(100) at the front of the table is also a real space hog.
From what I've seen the name function is not useful in a query that returns multiple rows. It's way to slow.
I created a subsite aware object_type and inherit from it if I need a subsite aware object. Seems to work ok but it's another join.
The real question is should all this stuff be in acs_objects making the table bigger, but the queries simpler or have a bunch of related tables meaning more joins but perhaps more tunable. I like the lots of tables approach because if you really use the object model you can add attributes to acs_objects but put them in another table and use get_attribute to retrive values on queries that return one row, but still have flexiblity to tune multirow queries. You also don't have to worry about messing up something that does select * from acs_objects
