The tricky thing facing developers is the fact that many of more useful API features of Select/Adjust (eg. Zip module, ImageFileRender) would be pretty essential to any app that used them. As such, unless the software is to be Adjust only (not really financially viable) then the code has to be reinvented for RO4 or Iyonix. If one is re-inventing code anyway, it becomes much easier to support a single code-path, rather than having different paths for different OS versions.
As an example, take OS3.60+ OS-based jpeg handling. In several apps we used this, as it seemed a good idea to embrace OS features. However, we found that there were problems with scaling (I think) and more significantly, if you had lots of images, they decoded graphics weren't cached, so the OS routines had to keep re-decoding, which could cause massive CPU overheads in some cases. In the end we reverted to the single code-path, and things were much better. Perhaps this is a bad example, because there were flaws in the OS routines, but it does highlight why a developer is more likely to create and use their own code, rather than rely on features not available in all OS versions, over which they have little or no control.