As far as I know, most game engines deal with animations as sequences of frames of given durations, and these durations are usually implemented as floats (if the base unit is seconds) or integers (if the base unit is milliseconds or microseconds). These types all fail to accurately reproduce durations such as 1/30 or 1/60 seconds. So, Aseprite’s use of integer milliseconds makes sense for more than just GIFs.
I suspect the limitation of floats and integers for durations is why aPNG uses the n/d format, it’s the only way to accurately preserve such durations, even if they’re not always accurately reproduced during playback.
Although n/d is the ideal option from a data accuracy standpoint, I think allowing a decimal point and precision down to the microsecond (e.g. 16.667ms) would be the most practical option, as it makes for the simplest UI (just a simple single textbox, like it is currently), is compatible with the existing milliseconds system, and plays well with timelines, while still allowing high precision. 16667/1000000 isn’t 1/60, but it sure is close, and it’s much closer than 17/1000.
If someone wants to get really fancy, it would even be possible to write an aPNG exporter that automatically detects approximate n/(3m) durations and provides the option to automatically convert these to the appropriate n/d (e.g. 16.667 -> 1/60, 958.333 -> 23/24). I bring up n/(3m) specifically because many common framerates are multiples of 3, and other common “easy” numbers generally work just fine as ms or µs (n/1000 or n/1000000).