An Office 365 admin can grant the Template Chooser an admin consent allowing the Add-In to access all defined resources on behalf of each user without the Template Chooser having to asking the user for consent. Additionally, it will unblock the scenarios where the user can not provide consent, such as for example access to the user's lists and libraries in SharePoint online. Learne more about the access scopes supported by the template chooser on the dedicated Data Access page.
Every time the Add-In wants/needs access to specific data in Office 365 for the first time it needs to ask the user for the permission to access that data. So for instance if the Add-In wants to read data from OneDrive it will have to ask the user if it is allowed to access the users data in OneDrive. The user can agree to this by providing a consent for accessing his or here data in OneDrive. This consent experience is provided by the data source - in this case by Office 365.
By providing an admin consent to the Template Chooser the admin can make all users within that Office 365 tenant more productive by saving each and every user having to individually consent for each resource separately. It will also reduce the questions users might ask in connection to dealing with the individual consent request they will face during their interaction with the Template Chooser.
We can actually not identify any risk by providing an admin consent. In case you want to recall your admin consent, you can always use the Azure AD portal to revoke any consent.
If you are a larger organization you might find this annoying, that all users have to individually consent to the Add-In accessing the users data for each data resource in Office 365. This has also an economical aspect as you can save the organization quite some time if you add the few minutes each users can save by having the resources they need pre-consented. So basically the larger your organization the more value doing an admin consent will bring. But we would reccomend to to this in all sizes of organizations as it just makes users more productive.
In your organization you might not want to use all features of the Add-In, hence you will not want to provide consent for a data source you don't want to use. Unfortunately, the current Azure AD architecture for providing admin consent is restricted to one single consent flow, meaning that we as the developers of the Add-In can only offer one admin consent flow for all customers. This means, we need to put all the scopes into that one flow to allow every customer to use all the features they wish to use. The drawback is, of course, that some customers are forced to provide consent for instance for accessing 'OneDrive', even if they do not want to use (deactivated) this specific feature. We are actively working with Microsoft on being able to improve this scenario, allowing customers to admin consent to only those scopes they actually want to use and not being forced to consent to all as it stands today.