To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.
The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.
That is, to be able to function these things need stuff like CreateRole, CreatePolicy, and the equivalent assignment actions (as your functions need a role and policy to execute under).
The AWS policy descriptors are not sufficiently robust to allow the creation of roles/policies that, themselves, only have certain policies/rules attached to them. That is, you either have the ability to create a policy of anything, or you do not have the ability to create a policy, period. Same with role creation.
Because of this, having the necessary permissions the framework needs to do what it says on the tin necessarily means it also can give itself -any other permission-. You can't give it the ability to create and assign policies, but prevent it from accessing, say, EC2 instances, because the role the framework operates under can create a policy for all EC2 actions, for all resources, and assign it to its own role.
So while, sure, it would be nice to enumerate just the permissions it actually needs, and what's going on behind the scenes, just so the user knows exactly what is going on, that set of permissions is still effectively administrator access. There's no security benefit.