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.