If you don't need those features, doas is probably a good replacement. But if you do, it probably isn't an option.
Sometimes less is more. My immediate response to that is that it sounds like needless complexity which can be a source of errors, bugs and security-vulnerabilities.
What typical use-cases do these particular features have?
For the io logs: auditing. And in some cases such logs are necessary for compliance reasons.
For wildcards: allowing to run a command, but only if they supply a specific option that makes it less dangerous. Now, you do have to be very careful when doing that, but there are cases where it is useful and explicitly listing every variation of options that is allowed isn't practical.
I also forgot to mention sudoedit. Although, making something similar for doas would be pretty simple, so I'm kind of surprised there isn't something.
Allowing a user to use systemctl with specific daemons, so ```systemctl * unit-name```, without a password. But anything outside of that I need a password.
It's more so the curious dev don't just go sudo bash and changes stuff willy nilly then forgets what they changed.
We do avoid wildcards like plague but honestly regexp support would be more useful, then our devs could just have say
^/bin/systemctl (start|stop|restart|status) app-([a-z0-9\.\-]+)$
To me this sounds like a feature for a non-default "root-manager", while the default should be kept simpler to avoid people falling into such traps.
But the point being that the users who have that also can just sudo anything anyways, and if an attacker is running shell commands, you're already in trouble.
I'm wondering if you're not right at this point though.