This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.)
The idea is you'd run batch jobs and services explicitly via systemd-run.
Security by default is usually a good default, yes.
systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place.
Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?
Security is a spectrum, and too much security means less freedom and shitty life experience.
I don't have a problem with a new tool such as systemd-run.
I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems.
Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.
This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.)
The idea is you'd run batch jobs and services explicitly via systemd-run.