Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation.
Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch.
Durations displayed to a user wouldn't ever be stored so the point is kind of moot.
Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.