The fundamental mechanism is as old as fork+wait themselves, of course. Handy command-line tools for doing this sort of thing have been around since the 1990s. It in no way began with systemd.
Daniel J. Bernstein famous daemontools package could be used without superuser access by users who wanted to manage their own sets of services. A user can quite happily set up a scan directory and run svscan against it. The only missing part, that just needed to be written by an administrator, is the infrastructure to run svscans for users automatically, which is of course just a system service that drops privileges and runs svscan as the appropriate user.
The same is true for all of the other toolsets in the daemontools family, from Laurent Bercot's s6 to Wayne Marshall's perp.
Service management toolsets that provided such infrastructure out of the box, rather than expecting the system administrator to set up such services manually from scratch, largely began with Upstart, whose init program had a "session init" mode, which wasn't quite per-user.
launch agents on MacOS are a similar idea, although launchd is strongly coupled to Mach.
systemd came afterwards. It can run in a per-user mode, with the system-wide service manager instantiating a template service unit for each user, on demand (via a somewhat complex combination of PAM add-ins, a Desktop Bus, and a "login" dæmon), that runs another instance of the systemd program.
Other toolsets providing this include the nosh toolset.
Further reading
