It was created by the Library of Congress for bibliographic purposes, hence approximate and uncertain dates. I agree that they have their uses. However it is also apparent that 8601-2 is trying to amend 8601-1 to fill the gap, in my opinion very badly:

- Sub-year groupings are not very well defined and you may want to avoid them, but if you want the basic approximate and uncertain dates you can't avoid them because they all belong to the level 1. Ideally each extension to 8601-1 should have been defined separately; they do have to be described altogether to avoid the conflict among them, but any part of the additional standard should have been optional.

- 8601-2 essentially took the whole recurring time interval mechanism from iCalendar and it is a simple textual format. Why not the same for extended date and time instead of sigils (e.g. `2021-03-09;SIG=P1M`)? Unlike 8601-1 it doesn't have an absolute requirement for usability. I can only guess but editors seem to have forgotten to harmonize different specifications.

Excluding the final monstrosity of an example in the GP post here — I think some of these would actually be useful in genealogical (family tree) research software — given the correct kind of UI.

Approximate dates, and unknown portions of dates are fairly commonplace in genealogy.

(No idea what the original author was thinking though — I wonder if the intended use cases are documented anywhere?)