I respectfully disagree. Fragmentation impacts both developers and the end users.
Developers:
There are a finite pool of people that have the knowledge to improve/write software. That group is further divided down into those that have the time and motivation to contribute to the open-source software. From there they are further divided among the competing projects that are doing the same thing. Example: GNOME 3 vs Cinnamon vs MATE vs KDE vs Trinity. Debian vs Red Hat vs Arch vs Suse vs Slackware. Therefore this fragmentation needlessly reduces the pool of available contributors.
Also, any software package needs to be maintained for so many different configurations. A very good example is the package management: Debian, Red Hat, Gentoo, Slackware each have their own package format. This fragmentation adds more boring workload on the maintainers. Now that we will have distributions with or without systemd, it means that if the software deals with the area affected, TWO versions need to be developed! Doing something twice is again wasted effort.
End User:
Fragmentation adversely affects the user because the software he/she needs may not be available for the configuration that it being used. It is hard to come up with example for systemd since it is such a system-level system. Much easier to use an example of window-manager fragmentation: A certain package may look terrible on the one that the user chose.
Even if the software is available, documentation may be only written for another distribution.
Finally, the user needs to choose a distribution to start with. The choice is literally overwhelming. Have a look at this timeline: Distribution Timeline. Now imagine it exploding even further into systemd using/rejecting versions. That much amount of choice is paralyzing.
In the end, fragmentation just wastes resources on doing the same things more than once. It is necessary if the constrain is quite severe, but right now in the community forks happen over something as trivial as library versions or the visual look!