It just depends on how you are using the JSON and where it fits in an application. If I'm using a static language, it is common for me to have a TimeSpan (or similar) type and standard rules for how it can be serialized (e.g. toString, toJson, etc). In this scenario, I don't care how it is represented in JSON, I just want convenient (de)serialization.

With your example, I would need to create custom parsing logic, and handle a dynamic number of JSON fields. But if a TimeSpan class had JSON deserialization built in based on the ISO8601 format, then I wouldn't need to do anything special. That's the benefit of using the standards. Same if I wanted to convert the JSON stringified format into a postgres time span there isn't any special parsing logic I need to do.

Yes, it's just a string in JSON, so it's not semantically special. But other languages that have a TimeSpan type could take advantage of the standard serialized format.

Here is an example of what it could look like in F#, no special logic for deserializing into a custom type:

    type MyEvent = {
      myDuration: TimeSpan;
      createdAt: DateTimeOffset;
      eventId: string;
    }

    let rawJson = 
      """
        {
          "myDuration":"P15DT5H0M20S",
          "createdAt": "2023-08-24T20:30:00Z",
          "eventId": "e_1234"
        }
      """
      
    let myEvent = JsonSerializer.Deserialize<MyEvent>(json = rawJson)