I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
It most certainly is if you manage servers!
Most performance evaluations include an uptime requirement. Most businesses it is 99.97% uptime while some Slashdot readers it might be as high as 99.99% or 99.9999% if they work at Amazon or a Wall Street trading firm where any downtime costs millions a minute.
If servers randomly do things behind your back or you restart one during a standard change and it doesn't come back up and your change window is between 1am - 3am (like my employer) you can be in hot water if you can't get it back up if something weird happens during a patch or other activity. SystemD's benefit is it's downfall which is that is event driven. Let's say theoretically you can have SystemD launch tasks or do something in the event your network is hacked or if one of the NIC teaming cards fail. That sounds cool. Problem is if it fails and does something that crashes it.
I am learning FreeBSD now more after I stopped touching it in awhile. Sometimes boring but predictable non event oriented boot only procedures are bah but predictable and nice. You know what you are going to get. It's in that ugly RC script hack but hey you can debug it!