Basically the existing CKA_ID and CKA_LABEL values are unsuitable for uniquely identifying and object on a given token as they are both not required to be set, and is not required to be unique, and are allowed to be modified.
What the original concepts where around the CKA_UUID discussion was to basically have a value that must be present, is provider-assigned, and is unique for the given provider - so that for any use referencing and object on a provider (either token or non-token) you can safely identify the same object across multiple sessions. This is the issue for which multiple vendors have provided their own approaches - and is relatively easy for implementations to support. The concept was also (like in KMIP) to not specify the format of the unique identifier (as we don't currently specify that for the CKA_ID or CKA_LABEL and we don't specify that in KMIP) so that whatever implementation limits exist within a provider are able to be handled. Whether and object is a token-object or not the same applies - we need to be able to uniquely reference it - in a reliable cross-application manner (although cross-application doesn't apply to non-token objects the concept isn't limited to token-only objects).
Making it optional defeats that purpose. Forcing a particular format (RFC 4122) will break the ability to implement for a large range of devices (dependency on a clock or on a specific unique device identifier). Leaving it such that basically current vendor approaches can be easily mapped is an advantage (and those range from a simple unique incremented integer, through to GUIDs)
Importing and exporting of objects between providers and attempting to provide a guaranteed universally unique identifier is a separate topic and should be kept separate IMHO - as it hits the whole issue of what are we attempting to achieve if we want to move objects between providers while preserving their entire state - and there is more to the state in most implementations that what is reflected in PKCS#11 currently.
Tim.