Creating the udev rule is not much longer than setting the option; maybe it would be better to "just" document this in the wiki (for example) and let people copy the udev rule from the wiki to their conf if they have this hardware.
By "better" I mean that, for example, each option makes the evaluation time longer for everyone.

There are already options for similar devices:

• hardware.onlykey.enable (defunct at the moment, uses 'builtin' instead of 'builtins' and requires a non-existing plugdev group, I have a pull request to fix this in progress)
• hardware.nitrokey.enable (plus hardware.nitrokey.group, which is not needed if the udev rule uses the uaccess tag to add an ACL entry for the current console user)
• services.trezord.enable (has similar udev rules, but also adds a systemd unit for a custom daemon)

The YubiKey (or any other security token) also needs udev rules to allow the console user to access the corresponding hidraw device, which is why systemd/udev introduced the ENV{ID_SECURITY_TOKEN} variable in lib/udev/rules.d/70-uaccess.rules to declaratively add the uaccess tag.

Using services.udev.extraRules in configuration.nix is not possible, because those rules end up in 99-local.rules after the 70-uaccess.rules that enable ENV{ID_SECURITY_TOKEN} and the uaccess tag.

Maybe a single option to enable support for all known security tokens would be the best solution.

This is has been done in #55741.

@abrenk what functionality would not work without ENV{ID_SECURITY_TOKEN}?

I'll close this since hardware.ledger exists now as @asymmetric highlighted. I think the ENV{ID_SECURITY_TOKEN} issue that @abrenk mentioned belongs in it's own issue, if it still is applicable.