First of all, I'm not suggesting removing the ability to define package-specific permissions. In Stephen's example of a base class that wants to "keep secrets", that base class itself may want define its own permissions. Or, perhaps restrict viewing to admins...
Or perhaps visitation to the UI pages is restricted to certain groups of users ...
Or ...
The point I'm making is that typically we'll view objects as being atomic, and won't be granting permissions to the various base types on an individual basis.
If we have a hierarchy like:
content_revision->image->wp_image_attachment
I'm unlikely to want to add "content_revision_read", "image_read", and "wp_image_attachment_read" permissions to each object just so I can allow a user to see my wp-specific type data ("where to display this") while simultaneously hiding the image the package wants to display!
One could kludge around standard permissions in Stephen's example. That doesn't require us to forgo standard permissions in the typical case.
There may be other reasons to do so, however...
I think Walter's comments can be addressed by proper use of context_id and security_inherit_p, combined with package-specific UIs that let admins choose permissions options based on clear English descriptions of what each option will do.
