The requirement to have a created property makes it more difficult to use deterministic IDs for SDOs are SROs, and the use cases for these have come up in several areas. For example:

1. Having a deterministic ID for a resolves-to relationship between a Domain Name and IP Address so it could be updated real time without having to store the ID and created date for the initial SRO.
2. Having a Malware object for a single file that always produces the same ID based on the SDO's creator and the file's ID (which in turn comes from its hash) so a secondary system is not needed to store these IDs.
3. Producing consistent Identity IDs for internal systems that want to avoid storing the UUID and can simply work with the organization's name and the fact a given organization created the object.
4. Providing deterministic IDs for locations with the same properties so that secondary databases are not necessary reuse country objects or GPS coordinates.

Since modified will still be present this would not break TAXII based sorting mechanisms if introduced in STIX 2.2. Likewise, it would not break revocation or versioning mechanisms as these both used modified not created.

The removal of created as a required field would simply allow for leaner messages to be sent, reduce the storage requirement for tracking when a STIX object with a given ID was first created, and because of these would allow for deterministic ID schemas to be more widely used across the objects.