Why is this the case? Do users need extra permissions to write extra fields into the journal?
Users don't, but the specific mechanism that systemd uses to supply the extra fields to journald is, currently at least, only aware of system-level units (and relies on write access to /run/systemd).
Although your user-level systemd manager could supply extra fields to journald directly, when creating the stdout-to-journal pipe for this service, this would only have effect on messages captured from stdout and stderr – but the fields couldn't be automatically attached if the service process itself submitted messages through /dev/log or through the "main" journald logging socket.
To solve that problem, systemd has chosen to have journald manually query systemd for the extra fields attached to the unit (as journald already knows1 which unit the process belongs to) – but as currently implemented, only the system-wide service manager (pid1) is being queried for fields attached to [email protected]; your user-level services are ignored.
1 (With short-lived processes such as echo there's also the problem of the process exiting before journald can find out which unit it belongs to. Unlike e.g. the PID or UID, which are attached by the kernel to each socket message, the kernel developers are steadfastly refusing to attach cgroup membership data so journald needs to get it from /proc/<pid> after the fact. Which is why you might see _SYSTEMD_UNIT= missing from some messages.)
User processes can include custom fields (except privileged _* fields) if they submit messages directly through the main journald socket. (This is already done e.g. by GLib2 logging functions.) For example:
logger --journald <<EOF
MESSAGE=Hello!
FOO=bar
EOF
(Ignore the --sd-param option if you find it in the manual; the "sd" does not refer to systemd – it's for structured data in the RFC 5424 "IETF Syslog" protocol.)
