The use of CKR_TEMPLATE_INCONSISTENT for a valid public exponent that a token wishes to reject for token specific reasons is documented as you noted.
"A final example would be a template with an attribute that violates some token specific requirement. Note that this final example of an inconsistent template is token-dependent—on a different token, such a template might not be inconsistent."
So if the value isn't completely illegal always then CKR_TEMPLATE_INCONSISTENT is meant to be the error return code.
This is what the lead in sentence of "CKR_TEMPLATE_INCONSISTENT shall be returned if the implementation cannot use the supplied exponent value." is also stating.
The specification is being entirely consistent in that handling. Stating "conflicting values" isn't indicating what the values conflict with - either each other or with requirements of the token itself. It is explicit that a token can have its own requirements which trigger this error return code which are different from another token - so it isn't about the relationship between the various attribute values in isolation.
This wasn't unintended.
Returning CKR_ATTRIBUTE_TYPE_INVALID would be inconsistent and confusing - as it is not the type of the attribute which is the issue - it is the value.
However the return of CKR_TEMPLATE_INCONSISTENT without indicating which attribute(s) are the issue is not all that helpful an interface.
We discussed a number of times that improving the error return handling for at least this specific error code would be useful - so the application has some way of figuring out what the issue is - but that is a separate topic.
Tim.