Rarely tested code is a breeding ground for bugs. Abstraction layers and compatibility layers tend to consist mostly of edge cases and rarely tested code. They cause significant amounts of bugs.
The best approach that I've found is to decide on an API to code against, preferably the API of your main target platform or at least something very similar to it. Any porting effort should then concentrate on providing that same API, even on platforms that are missing critical libraries. The upside of this is that you write your regular code just as if you where only targeting a single platform. Any bugs caused by the porting effort are unlikely to be noticed on the main platform, and neither does most of your users have to pay for the overhead of routing every system call through endless layers of abstraction.
As for whether it is actually worth bothering to port applications to less used platforms, I think the answer has a lot to do with what type of application you're writing. systemd is pretty tightly coupled to the Linux kernel. It relies on many features of the Linux kernel that only have very rough equivalents on other platforms. While it would be possible to provide a unification layer that made systemd run BSD, doing so would likely be more work than rewriting systemd from scratch for BSD. This is not the case for higher level applications like emacs or Firefox. While they occasionally make use of low level kernel interfaces, that is the exception rather than the rule. I think we should accept that some subsystems, even though they run in userland, are tightly coupled to a specific kernel. It makes sense that init should be such a subsystem.