All it takes is the motivation, a group of likeminded individuals and the willpower to deliver a dist that does not use systemd. I expect most packages in the debian universe have no deps on systemd and therefore no work required to support those packages. So we're talking system packages, some daemons and maybe a few shims for edge cases.
You're implying that it would be easy. I'd like to think you're right. One group has already announced such a derivative. I'd love to see it succeed, but I'm not holding my breath. Maintaining a linux distribution as well as debian does, including timely security updates, package builds, downstream bug tracking, release management, and uniformity across so many installations as to form a vast support community, is a much bigger job than one might think. There's also the issue of various unrelated but popular packages developing dependencies on systemd, which means any such derivative distro would also be in the business of developing and maintaining forked versions of those packages; also not a trivial task. I guess we shall see.
As for why there are only 2 dists left not to have gone to systemd, perhaps that should serve as a clue in itself.
Many of them seem to be derivative distros that simply don't want to diverge from their upstream distribution's init system, so they have little choice. (Counting them as independent decision makers would be dishonest.) As for the upstream distros, I think it's more telling to note how very divided their communities were in the vote for/against systemd. A strong argument could be made that anything so integral to the core of an OS distribution should not be replaced with something so divisive to the community.
Speaking for myself, I'm a bit disappointed in the loudest factions of this disagreement. Most of what I see in these discussions is two mobs of people pushing for a decision *right now* (meaning this year, or next). The voices shouting "we need systemd!" or "we need nothing of the kind!" dominate the discussion, while a third option seems to have been forgotten: How about waiting until something can be developed that offers important core improvements over sysv init, but isn't as invasive as systemd? Most of us can obviously get by just fine with our existing init systems for a little longer; we've been doing it for years. The uproar over the topic is surely enough to motivate the development (or modification) of an init system that most of the community would find suitable. I'd love to see that happen.
In any case, I think the original question here has been answered. :)