They are partially used but as Jon mentions the auto-generation bit never got done. Bits and pieces were implemented in acs-templating but it's not fully functional.
There are in essence two types of attributes that are supported, those that are stored in your type's custom table and those stored in acs_attributes. The reason for the latter is to allow for attributes that can have multiple values.
The first type are almost uniformly set by explicit updates on the table within the toolkit rather than set by the slower "set_attribute" method (if you change more than one attribute, the latter approach will result in multiple updates, *slow*).
So you can think of the attributes stuff serving a descriptive rather than functional purpose for attributes of that type. As Jon mentions, they make possible the auto-generation of forms by the templating engine and similar things. We might want to explore this in the future.
The second type - attributes that can have multiple values and are stored in the attribute values table - is hardly used, and that's just as well IMO. The only way to set such an attribute or get values is through the attributes API.
I haven't had time to go through all this in exhaustive detail, but for our second development/release cycle I've been thinking we might want to get rid of the second type of attribute altogether and maintain the first type strictly for descriptive purposes, i.e. to give a db-independent way to autogenerate forms and the like.
I think it makes sense to use the RDBMS as an RDBMS rather than to try to totally hide it in an abstract object-attribute model. If the entire toolkit lived within the object-attribute model it would be substantially slower (which is probably why various aD implementors used UPDATE directly in their code for attributes stored in the type's custom table).
