You can simply have systemd run a shellscript if you don't have time to fix things. But systemd can be configured to deamonize your service, to restart it if it dies, to make it drop privileges, to make run itself in a restricted environment, to shut down when there is no incoming traffic and a whole host of other often useful things. In addition, systemd will put each service it runs into it's own cgroup, meaning that unlike any other Linux init system, systemd can track manage daemonized subprocesses of the original service process, which is pretty neat.

Almost all of those things can be done in shellscript too, but you have to do it all manually, which means very large amounts of code, which makes it error prone. Yes, systemd has it's own configuration language that you have to learn, and like all custom DSLs, it truly sucks balls sometimes, but at least it's a far easier configuration language to use than shellscript. Shellscript is an amazing invention and fantastically useful for some things, but it is far too low level for managing a service. It's easier to use systemd.

Another way in which systemd is easier is that you usually don't have to specify your dependencies. The normal way systemd handles dependencies is that each service declares what ports it will open, and systemd opens those ports for the service and hands them in on startup. These dependencies will then simply be implicitly managed by the Linux kernel blocking processes that are waiting for IO, leading to massively parallel startups which is the secret to the great startup times of systemd. But for most people, startup time is irrelevant, the actually useful aspect of this feature is that you almost completely remove the error prone and fragile process of dependency management from writing a service startup script, leading to a simpler, more easily maintained service with fewer moving parts.