It depends on what scenarios are relevant in your case, it depends on architecture that you want to implement. Some examples:
1) If in your case the risk of compromising of account with low permissions is higher compared to accounts with high permissions, then sending permission info in the token increases your risks.
2) If in your case all accounts can be equally easy (or equally hard) compromised, then sending permission info doesn't change your risks: The attacker will compromise an account with high permissions (e.g. admin account) and, even if permission/authorization logic is embedded in the application not in the token, he will get all permissions of this account.
3) If in your architecture you want to have "slim" application modules / services, that provide as high performance as possible, as small response times as possible, use as little resources as possible, or if integration with authorization / permission system is too expensive, then may be you want to eliminate any logic related to authorization / permissions in the modules / services that implement business logic. On some nodes you can deploy authentication and authorization services. On many other nodes you deploy (or run containers, doesn't matter) services that implement some business logic. And you may want that these services don't care about permissions and just trust the tokens that the other part of your application issued. Then sending permissions within tokens could be a good approach.