I agree, if you can make software that runs on all versions then it's kinda cool to do so. Bonus points if it can also make use of later OS features.
Personally I'd even try to support the alpha versions.
Be careful of what you wish for. The Kickstart 1.x APIs were pretty rough going, which is particularly evident for the dos.library. The dos.library (and its associated disk-based software, such as the shell commands) kept evolving through Kickstart 1.3. Not many people know how much work went into dos.library post-Kickstart 1.2, but it's among the few areas of Kickstart 1.3 which saw the largest number of changes. From what I can tell the changes are mostly bug fixes.
By the time Kickstart 1.3 came around documentation for dos.library had improved considerably, but there were still major gaps (e.g. how did the shell interface work, how did the file system interface work, etc.). As an application software developer you could finally get by, knowing why certain data structures had to be aligned to long-word memory boundaries, why strings passed to dos.library could not be longer than 255 characters, why dos.library internal pointers had to be translated, why you needed at least 4000 bytes of stack space to be safe when calling dos.library functions and how the most important "documented" data structures would hang together.
Still, I suspect that the further back in time you go, the more surprises will be waiting for you in the dos.library data structures and its inner workings. The same would of course be true for all the operating system components, but dos.library is the most obscure among its peers. Not by design, but more or less by accident. If memory serves, integrating what became dos.library and the shell commands into the Amiga operating system was one of the significant reasons why Kickstart 1.2 took so long to come around.