It replaced a system of startup scripts usually called System 7. Basically this was individual scripts to start various functions, and a sort of “super script” which controlled which scripts were launched at what point during start up. Positive things about this system was that the scripts were editable text files (assuming you had root privileges), so you could see exactly what the script was trying to do, and it used the standard text logging method (syslog) and a similar shell environment to the normal command line. This simplified debugging. The downside was that over time the scripts became complex and hard to understand. The system didn’t have a direct method of representing dependencies, such as “don’t try to update the system clock from the network until the network is up and running.”

Systemd is a package of programs used for just about all process control, not just startup. Processes have a service declaration file, which basically defines the conditions under which the process is started and stopped. Here you can define dependencies, for example. A service declaration file is not a bash script - it is interpreted by the systemd binaries. Logging in systemd is not by text to syslog, but in binary form to a systemd log, which you can access through another systemd utility, journalctl.

Systemd provides a declarative way of defining startup and other process dependencies - that is good. The actual execution of the systemd binaries and the logs produced are more opaque than under System 7, which tends to make system admins a bit nervous. It seems to be pretty reliable now, but in the past I experienced at least one case where a systemd update made a Linux system unbootable, and another case where it made debugging more difficult (the same shell script behaved differently when launched from the command line vs being launched by systemd). Still, it is a standard part of most Linux distros now.

EDIT - For System 7 read “System V” - my mistake, sorry.