"All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)"
Yes. But that's completely beside the point.
The problem described is not that old stuff won't work/is portable; the problem is that new stuff, stuff that use fancy systemd-specific parts, are not portable. This means there will be great services, down the road, that people will want to run on other UNIX-like OSes than Linux, like say, FreeBSD or OSX.
Before systemd, this was easy to accomplish. After systemd, you need to write a software abstraction layer that hides the systemd-specific parts. It's a giant problem just waiting to come up and bite someone in the ass.
You have to realize that the reason future software project may have trouble running on non-systemd platforms are because those platforms are sagging hopelessly behind the technology curve
Upstream projects are using systemd features because they solve real world problems in an easy and distro-agnostic way, and that systemd software is actually much more portable across systemd distros, than Linux software ever was.
The important point here, what so many seems to miss, is that upstream projects like KDE and Gnome, happily will make their software run on non-systemd platforms if the non-systemd platforms would actually help out to accomplish this. Upstream projects don't need shims or compatibility layers; they just want API's and software functions that are comparable to systemd's, but no one seems to provide them with this.
Take fx. KDE's new login manager (the old "KDM" doesn't support Wayland etc). They choose an emerging project with good systemd and Wayland support, but since this was a new project, it didn't support ConsoleKit, that is the only existing alternative to systemd's "logind". The problem is that ConsoleKit is basically dead and bit-rotting, and hard to program against, and KDE's own developer resources are stretched to the limit, so adding ConsoleKit support on their new login manager just isn't being worked upon. And no one outside KDE, from non-systemd platforms are stepping up and helping KDE either.
So that component is now "systemd only", simply because KDE have no real alternative, and no one are helping them.
So either *BSD developers start helping upstream DE projects to work on their non-systemd platforms, or they will have to live with reduced DE functionality. Hardly unfair that they will have to provide a minimum of support to have advanced DE's at their disposal for free.