Is telling systemd to reload .service files after changing them a "script that doesn't make sense" to you?
Makes plenty of sense to me.
90% of the scripts are to do that, or to recompile .pyc files when you install a new module or when you install a new version of python.
Arch tries to generally avoid changing "default" behavior. Systemd doesn't automatically do that, so Arch won't ship systemd like that. Arch also generally avoids shipping with timers enabled.
Out of lazyness or out of actual usefulness to the users?
A little of column A, a little of column B. Arch is very much a distro developed for the packagers. OTOH, as someone who often has to dive into the details regardless of distro, I generally appreciate the plain-vanilla approach to arch's packaging (since I can just set the package up as opposed to undoing whatever helpful defaults and changes Debian's decided to add).
I personally (using Arch, btw) definitely prefer Arch's behaviour. If I update or install a daemon, I generally want to configure it before (re)starting it.
Restarting it and telling systemd the .service unit has been changed aren't the same thing.
Arch does daemon-reload after service file update: `(2/5) Reloading system manager configuration...`
Arch does reload service files (not user ones though) IIRC. I also disagree with GP, I don't reboot, I use needsrestart and/or my own logic (simple grep for "(deleted)" within proc maps and then show cmdline).