1) In the linked scenario. Why would there be need for a refresh-token? if the token expires their (web)application would just send for a new token using their clientid and sclient secret?
Refresh tokens are used if the client makes a delegated call to your API.
In this case the token will contain the currently logged in user's info as well.
The client can use the refresh token to get a new access token for your API for a specific user when the access token expires (instead of redirecting them to login again to get an authorization code etc.)
If they call your API purely using client credentials (id + secret) then there will not be a refresh token.
2) We have 100+ affiliates. Almost all of them will have same permissons, but we still want to give everyone a unique clientid/secret. How do we practically do this? Is manually in azure web portal the only way?
To get a unique client id for each affiliate, you must create a new app registration for each of them.
You can automate this process by creating the Application and Service Principal via one of the Graph APIs (Azure AD Graph or MS Graph):
Note the MS Graph endpoints for applications are still in beta and not recommended for production use.
This is one of the very few cases where Azure AD Graph API is the supported case.
You will need to create an Application for each affiliate (remember to create the passwordCredential (secret) as well),
then create a Service Principal based on the Application,
and then grant the Service Principal rights to your API.
If these are application permissions, you will have to create appRoleAssignments.
