Recs.
Updated
Specs
Pros
Pro Cgroups processes control
Systemd groups all processes by services using Linux's cgroups. Think about memory/cpu/tasks/IO/Net limits and accounting for any service.
Pro Default for many popular distributions
Systemd is the default init system for most popular Linux distributions (Arch, Debian, Ubuntu, openSUSE, Fedora, etc.) Therefore there is an insane amount of support behind Systemd. Choosing Systemd means running with the herd, which comes with it's pros and few (or none for some people) cons.
Cons
Con UNIX-like isn't the same as the UNIX philosophy
One of the main argument that people who are against using systemd is that it does not follow one of UNIX'S core concepts: 'Do one thing and do it well'. Instead, systemd represents a collection of dozens of tightly coupled libraries, with responsibilities that exceed those of a simple init system, since it also tries to handle things like device management, power management, mount points, cron, encryption, syslog, network configuration etc...
Con Too monolithic
It tries to do too much - most people who use systemd aren't even aware of most of the features and don't really use them. It makes can be with complicated to deal with, and it's possible that in a few years this project will be a nightmare to maintain, and the users will feel the effects.
Con It's all or nothing
While it is technically possible to use software without SystemD, it really is true that it is "almost impossible" to use software without it, given that all the hard porting work to other init systems has not been done already for you, or given the fact that you are trying to install unported packages directly from the authors (either from binary, like a DEB file, or from source.) Consider the following:
Every major Linux distribution runs SystemD as an only option for init systems.
Around %95 of GNU/Linux users use SystemD, give or take.
SystemD makes things easier for lazy developers (at a cost, however.)
Therefore, most software packages that depend on an init system are developed with inherent and sole SystemD support, in favor of the status quo. While distributions such as Artix-, Gentoo-, and Void Linux have been able to correct packages that depend on SystemD, it is not the easiest to do so. Developers and users wanting to package their own software or build software from source may give up trying to work without SystemD since the software may need to be edited for extra compatibility.
Con The new version does not consider backward compatibility
They just remove the features they think are "incorrect".
Con systemd-DHCP cannot update subnet after reconnecting LAN from work to home
DHCP client that is builtin the systemd is really simple and rudimentary. Won't work with Verizon/Comcast DHCP ISP servers directly (must use their modem).
Other DHCP client can, like ISC dhclient, or dhcpcd.
Con Lead developer shows near complete lack of care for standards of quality needed for developing a part of an OS as integral as the init system is
Recommendations
Comments
Flagged Pros + Cons
Con Uses Confirmity as a Philosophy
While it does have many features, SystemD is designed with a pattern of making choices for the user. Since it is not easy for the user to override these decisions, SystemD essentially follows the "knows whats best for the user" philosophy.
This may remind the reader of Apple devices, where all the hardware looks the same, all the software looks practically the same, and the only customization options are wallpapers, physical stickers, or phone cases.
Pro vulnerable
To much features provides alot of surface to attack.
Most common target for attackers as is present in mostly distributions.
Con Not needed on the most systems
It is not useful or much faster than SysV-init on desktop or single-user systems.