It would be nice to add some systemd hardening options here.

What do you mean?

I think he means:

Can we run the daemon as a DynamicUser=yes instead of as root

Also we could set things like:

RestrictAddressFamilies=AF_NETLINK
PrivateTmp=yes

Etc.. (See man systemd.exec for more isolation options)

However I expect that this unit probably has to run as root to be able to create new input events

I'm going to take a look if this is possible to harden by running as a less privileged user. But I'm also not expecting much.

Even if you still end up running as root there are some settings you can apply to limit the abilities this service can have on a system. Though still hoping for a non root user, maybe with some capabilities or something.

I was reading the manpage of systemd-udev-settle and it said:

    Using this service is not recommended.  There can be no guarantee that hardware is fully discovered at any specific
   time, because the kernel does hardware detection asynchronously, and certain buses and devices take a very long
   time to become ready, and also additional hardware may be plugged in at any time. Instead, services should
   subscribe to udev events and react to any new hardware as it is discovered. Services that, based on configuration,
   expect certain devices to appear, may warn or report failure after a timeout. This timeout should be tailored to
   the hardware type. Waiting for systemd-udev-settle.service usually slows boot significantly, because it means
   waiting for all unrelated events too.

I also saw that the example upstream provides doesn't depend on it https://github.com/philipl/evdevremapkeys/blob/master/examples/evdevremapkeys.service

Why do we need it?

From the source code of evdevremapkeys it seems they subscribe to udev events properly; so I don't think there is any need to wait for systemd-udev-settle

https://github.com/philipl/evdevremapkeys/blob/6626275333818fbdedc9b6ab20dc12531e29b399/evdevremapkeys/evdevremapkeys.py#L344-L345

Whoops, I did indeed copy this mindlessly this from somewhere else in nixpkgs during development and then forgot to actually make this sensible :). I've updated the service definition to reflect upstream's service example.