I would say most of it is unnecessary buzzwords that don't help explain it. The whole thing can be simplified to something like "systemd is a task runner that has a dependency graph and transactions". That should also be fairly straightforward to you if you've used it a few times.

I'd say the other mistake the article commits is by trying to paint this as being a very complex design for the problem space. It's not when you consider the design constraints. You want services to have dependencies, and you want the updates to the unit files to be committed atomically to avoid stale data. Hence, the dependency graph and the transactions.