As written the user service creates a process storm that results in the application not being loaded at all. When examinig the logs the pattern is like this:

$ journalctl --user-unit=redshit.service

ene 09 06:55:39 arbegas systemd[632]: redshift.service: Main process exited, code=exited, status=1/FAILURE
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Unit entered failed state.
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Failed with result 'exit-code'.
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Service hold-off time over, scheduling restart.
ene 09 06:55:39 arbegas systemd[632]: Stopped Redshift display colour temperature adjustment.
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Start request repeated too quickly.
ene 09 06:55:39 arbegas systemd[632]: Failed to start Redshift display colour temperature adjustment.
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Unit entered failed state.
ene 09 06:55:39 arbegas systemd[632]: redshift.service: Failed with result 'start-limit'.
ene 09 06:58:03 arbegas systemd[632]: Started Redshift display colour temperature adjustment.
ene 09 10:02:12 arbegas systemd[632]: Stopping Redshift display colour temperature adjustment...
ene 09 10:02:14 arbegas systemd[632]: Stopped Redshift display colour temperature adjustment.

The process is started too fast for systemd to cope with and to prevent a DoS by resource exhaustion it kills it for good.

In my laptop (no speed daemon, tbh), I fixed redshift's start by using the followng override lines:

[Unit]
Wants=base.target
After=base.target

[Service]
Restart=on-failure
RestartSec=1sec

I depend on base.target instead of default.target because I want to use redshift even when booting to a console and I set Restart to on-failure, because there will be times when I may need to kill redshift forcefully. RestartSec fixed the process storm.