There is zero security concern for non-SECURITY-DEFINER functions, since they do nothing callers couldn't do for themselves. For those, you typically do want to grant out permissions. As for SECURITY DEFINER functions, there is no reason to make one unless it is meant to be called by someone besides the owner. Perhaps PUBLIC isn't the scope you want to grant it to, but no-privileges wouldn't be a useful default there either.
No privileges would be a safe default, not entirely unlike the default "can only connect from localhost" pg_hba.conf, …
In any case, changing this decision now would cause lots of problems, such as breaking existing dump files. We're unlikely to revisit it.
… but, yeah, this would be rather hard to change without causing more trouble.
As noted in the docs, best practice is to adjust the permissions as you want them in the same transaction that creates the function.
I wrote a function which resets the permissions on all objects in the specified schemas to default. Then for each project I have a privileges-granting file which starts by resetting all permissions, then grants exactly the permissions I want. Most of the resetting is done by checking the existing privileges and revoking them; then it ASSERTs that this leaves an empty ACL, and finally does an UPDATE on the relevant system table to change the ACL from empty to NULL. For SECURITY DEFINER functions, the reset function then revokes PUBLIC privileges, leaving it to the specific project to grant the appropriate privileges.
BTW, the reg* types are amazing for writing this kind of stuff. Makes all sorts of things so much easier.
