One of the authors here - while it is a best practice to restrict the roles any identity can assume, following the concept of defense in depth it is also good to use trust policies on the roles to be extra safe.

I'm not sure if I'm reading this correctly. The statements below are my understanding, but it'd be great if you can confirm to provide more color.

The pre-patch setup would just make the implicit trust policy explicit, meaning any user or role in the account with `sts:AssumeRole` on `*` could assume the role (which is still the default when not trust policy is specified).

This change improves the posture by adding a trust policy to the role that prevents any roles other than those two listed from assuming the role. So this is purely a defense in depth measure, and not really a security vulnerability (unless we say the default, implicit trust policy is a security vulnerability itself :P).

Another default policy to consider is any Lambda function role. They never specify which Lambda can assume them (because that would create a cyclical dependency). That means anyone with permissions to create a Lambda will be able to technically assume this role.

Just like you, I'm not arguing the defense in depth part. Always a good idea to put fine-grained permissions where possible. But I also find the "vulnerability" part a tiny bit overstated.

That's a bit different and (like ec2 and other services) governed by IAM:Passrole. Whoever creates the lambda or ec2 needs to be allowed to assign that role. Otherwise it would allow privilege escalation.