Part of the answer lies in determining what purpose an individual query has in gaining access to the metadata in acs_objects.
If you are going to assume some non-standard interpretation of an acs_objects field, then don't join, store yourself instead.
On the other hand, if you -strictly- interpret fields in acs_objects according to the original meaning and intent, then a join is ok. This means avoiding application-specific interpretations entirely.
This is going to hold true so long as you believe your interpretation of acs_objects field values will continue to hold over the life of the app.
Many people are advocating quick changes to the data model, a surefire way to keep the core unstable. On top of that, interpretations on fields in acs_objects, once correct assumptions, could become package breakers, as a result of changes in how data in core tables is expected to be interpreted.
Lack of maintained documentation will extend that effect over the entire time docs continue to be ignored: if you can't find out the correct way to interpret fields in tables you don't create, how can you build anything that uses those tables and have a reasonable expectation it will work?
What I've said for the acs_objects table holds true for all other tables in the core kernel, and really for any table that you did not create.
