That’s not quite correct, because in the current LTS version, 26.04, chrony has replaced systemd-timesyncd, which is why that command failed. timedatectl, while geared towards systemd-timesyncd, can still be used without it, albeit not all of its commands.
The real reason for this output:
is very likely connected to this question:
which you didn’t answer, so I’ll hazard the guess that you are, in fact dual-booting with Windows, which does expect the clock to be in local time, whereas above command shows that the default on Linux is UTC (RTC in local TZ: no). Booting Windows in between Linux sessions will thus, in your case, always cause a clock offset of one hour, which is just too big of a difference for chrony to cope, without additional measures. As a timekeeping daemon it’s supposed to adjust for small drifts in the millisecond range; seconds, tops, not hours. That kind of offset is cause for alarm in its world and hence it denies service (System clock synchronized: no). You’ll probably find messages to that effect in your boot logs.
Long story short, it wasn’t a missing systemd-timesyncd causing this, and you might want to revert that change back to chrony, if you want to stay with Ubuntu defaults. Then you need to decide, which system to change. While it may be tempting to just RTC in local TZ: yes, that has other implications, like a warping clock signal on DST changes, which will upset Chrony, if it happens in its absence.