I run a bunch of background jobs like harvesting podcasts that are released
weekly, collecting weather stats for my garden watering system, monitoring
my power feed and UPS, collecting ADSB  data, etc. I don't think of those as
'system' services, so I run them in my own cron jobs. The system works well
because even if my system reboots on a power glitch, or my session crashes,
the jobs still run--but in the systemd world it wouldn't work.

Why would't they? If you want to to run your own stuff independent of
you being logged in then do "loginctl set-linger" on your user and
it's done.

The logic in systemd is more strict on putting boundaries on resource
usage, and thus will by default not allow you to consume resources
while you are not logged in. It's really how this always should have
been designed. However, we fully acknowledge that there are many uses
where the ability to run stuff independently of any login as your own
user is fine, but you need to turn on lingering for that (which is
privileged), so that this is explicitly marked OK.

It IS very useful for systemctl to prevent resource leaks by killing errant processes (hanging browser, etc)---however, as we discussed, some processes should not be killed; I know which processes I want to annoint this way, and I take responsibility for their possible misbehavior.

I understand that set-linger disables process harvesting for all processes in the session, though, and I would like to just do it only for SOME processes.

I guess I could create another user for the persistent jobs and set-linger that session... but it gets complicated.

I think it's a better design if I could designate individual processes using my UID as set-linger. I remember talking about remote sessions with long-running jobs, and how the connection timeouts caused by remote clients or network routing prevented their completion. The solution was IIRC running them in tmux/screen. Here also, it'd be nice if I could designate 'my-long-running-service-like-executable' as eligible for lingering.