Today's definition of Read Only user might be good only for today, given that there are several new AWS Services and Capabilities being released quite frequently. Today's read only user wouldn't be able use the new AWS Service which went live and opened for public use last night; this is purely due to the way IAM Policy document was constructed as it would have the citations of the each verb and AWS Service. Though the policy can be edited; it may have to be edited in multiple places for Role / Groups / User Profiles.
There wasn't a placed holder which would define and hold the prolicy(ies)'s permissions together. The closest was to cookie cut the policies together. Long story short, though the READ-ONLY Group and READ-ONLY Role would have the same set of permissions there wouldn't a relationship/link which can be leveraged. Managed Policy was like God Sent to the AWS Cloud.
Things would further be messy when there are resource level permissions are being used.
The best part of was the categorization of AWS Managed Policy and Customer Managed Policy. So all the changes can be effectively done at a single place.
I tried to sketch a picture of a scenario how we visualize the scenario (below). The whole idea is to effectively leverage the power of the indirection introduced between IAM entities and Attachment of the Managed IAM Policies. We would like to have a Manage IAM Policy Library [Mix of out of the box – AWS Managed Policies and Custom Managed Policies ]; and have them attached them to the IAM entities.
Having the possibility to only attach only 2 Managed Policies to an IAM Entity would be a major limiting factor ( in my opinion ) to get the full potential of the Managed Policies [ Version Control, Easy Attachment & Detachment ]. However functionality wise the limit of just 2 wouldn't stop to define an IAM Entity [concatenate all IAM policy document Content] but it would be pretty exciting to define any IAM Entity [ User, Role, Group ) with any number of the Lego Blocks from the Managed Library; again the best part is all of the Lego blocks are version control with rollback. The policy definition can be done in a single place with having to do an dependency check (or reverse engineering).
In short the current count of 2 wouldn't be adoption enabler against the traditional inline policies considering the possibilities & potential of the Managed Policies.