That really depends on the complexity of the permission list you’re planning to store 
If you do end up going down the metadata route, then I would recommend using user app_metadata; user user_metadata is user self-modifiable, which is typically something you would definitely not want users to be able to do! Alternatively, perhaps take a look at something like the Auth0 FGA project? It might be just what you’re looking for - or if not, at least give you some ideas 
These permissions need to be retrieved on every request to my back-end API. (I could cache them, but I’m trying to build my API statelessly). Since they come from
/user_info, i.e. the authentication API, not the management API, I figure I’ll be OK with rate limiting.
This sort of fine/finer grained authorization use case is not uncommon. And for these scenarios the recommendation would typically be to add the authorization permissions as one or more custom claims to the Access Token JWT. Assuming the permission complexity won’t end up bloating the JWT that is. You can also add the same custom claims - or some additional (custom) claims based on the permissions - to the ID Token JWT too, if the UX needs to reflect what the user is allowed to do. Remember JWTs are signed, so it’s impossible to tamper with the data. And because JWT contents is easily (machine) decoded, you mitigate any additional API calls (e.g. the call to the /userinfo endpoint from step 4 in the flow above)