Object types should be objects, or at least that's the conclusion some of us have reached in earlier discussions. The main issue would be the writing of upgrade scripts that wouldn't break existing sites. A couple of us have discussed implementing "object proxies" (our made-up term) for object types that would give us an object handle for an object type in a way that would make upgrading existing installs easy.
acs_attributes ... if they were objects one could use permissions to control who can read/modify object attributes on a per-type basis. The expense involved here would be relatively low. If each attribute value were an object (giving permissions control over attributes at the per-object level) the expense would be horrendous, so that won't happen.
min_n_values and max_n_values govern the min and max numbers of the attributes you can assign to an individual object. Obviously this doesn't work with attributes stored directly as columns in the object type's table, only for those stored using the (slower) generalized attributes table.
enum_value and enum_prettyname ... software engineers seem to believe that identifiers can't include spaces even if they're surrounded by quotes for some reason. :)
your last question is related to the first question and that has been discussed, too.
In general, I think you'll find that many would like us to move to a more lightweight object model rather than a more heavyweight object model, and some of your ideas might be viewed as moving towards the heavy end of the scale. In practice the more dynamic aspects of the object model are rarely used by package authors.
