Performance vs. clean design? I thought it came down to what the requirements were, first off and if the fields added really belong to every acs_object.
If it is conceivable that someone would want an object to have zero or more packages or subsites it should be related to, you are stuck with a mapping table. Performance cannot be deteremined until someone lists what they are trying to do, why that is curretly hard to do, and what the new solution would do to make the situation better. You also need to include negative effects.
If you move package_id out of object specific tables, then display inside the application requires an extra join. But it makes it easier for someone to find all objects related to a package. Which is more likely to impact performance? What if you need a one to many relationship?
Many basic objects don't need this, and package_id and subsite_id could never contain a valid value. users, parties, group, rel_segments, acs_rels, etc. Acs_objects needs to contain fields common to _all_ objects, or at the very least only fields which could have valid values for all objects.
Finally maybe some extra fields could be removed from acs_objects: context_id. It hasn't been considered yet, but it might be useful to have more than one context for an object. Also, a lot of applications don't even use this field, so it has a zero or more relationship to other objects. (If you used a tag of 'context', maybe you could use the same object_map table.)
