Argument: Attribute domain tokens allow you to generalize and specialize attributes

It's true. They do. This token has truly been useful since its introduction in DITA 1.1, and is hard to get around.

Attributes don't have their own @class attribute.

If I specialize @props to create @pain, and then specialize @pain to create @intheneck, the only way for a processor to follow the specialization hierarchy is to examine the @domains token: a(props pain intheneck). This is important because if I use a DITAVAL to filter out @pain values, I might plausibly need to recognize them @intheneck. So to speak.

Generalization of @intheneck is also plausible, but as unlikely as any other generalization process. That said, if it needs to happen, the only way to generalize today is to use that token.

Alternatives?

We could just say "if you want to specialized one attribute to another, use subject schemes".

They're currently optional and not directly tied to the grammar. But as an existing, valid alternative to an uncommon problem, I'd personally be willing to require a subject scheme instead of requiring ugly domain tokens. Maybe that's just me.