I don't believe that this would be the easier option, even in the long run.
The "threshold" when backporting code from AmigaOS4 to AmigaOS 3.x could still be accomplished with reasonable effort (time and manpower) was crossed in about 8-9 years ago. Ever since then new data structures and APIs have been added to AmigaOS4 which significantly increase the difficulties of backporting code.
This happened at Commodore, too, when Kickstart/Workbench 2.x was under development. The toolbox became larger (double the ROM space, double the leverage afforded to software developers), and it became more and more difficult for Commodore to provide the same tools to developers who wanted to use them both in 1.x and 2.x applications.
There weren't many such tools (I remember "amigaguide.library" and the Installer), and there were some 3rd party solutions such as a disk-loaded "gadtools.library". But inside the operating system, the new APIs and data structures created more tightly-coupled code, saving ROM space and allowing for more robust code to be written.
Backporting such code at some point means porting practically everything, because you cannot always conveniently resolve the new interdependencies. Even if you tried, you'd run into practical problems for a hypothetical AmigaOS4 for 68k: AmigaOS4 is designed for a platform with much more RAM. As these things go (Moore's law, etc.) it also requires a more powerful CPU to run smoothly than a 68k platform could deliver (unless you consider emulation a target platform that makes good business sense). Finally, that complex port would have to be tested as well, which is no small challenge to begin with.
OS4.1 runs nicely on a poxy 603 with 256MB RAM and RTG, no reason why it shouldn't perform just as well or better on an Apollo core with more/faster RAM and faster RTG.
Especially if/when the Apollo is available in ASIC form.
Majsta talked about creating an entire computer at some point in the future, would be great if it ran a 68k back port of OS4.1.
