Yes, I do use --user where possible. Because resource limits are per-user on UNIX, I tend to run every program and every instance of a service as a separate user. cgroups/containers make this less necessary, but old habits die hard.
The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem.
When runit/daemontools, you "debug" a service by typing:
/path/to/service/run
into the terminal. Everything is sensible: grep the output just works. You can use tools familiar like strace/dtruss to "look inside". A unix user can easily leverage their experiences to administer a small unix site, and grow their experiences into larger sites.
With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that.
Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes.
Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.