I understand most of the workflow except when the secret_id expires.
Who is responsible for providing a new secret_id at that time ?
At first, it should be a separate entity.
No, there are reasons someone might prefer to use AppRole with non-expiring SecretID over simple tokens:
You can’t create non-expiring tokens apart from root tokens, but with AppRole you can create non-expiring credentials with particular policies. This may be important for example, when configuring credentials in an environment where there is no option to use a trusted orchestrator to automatically rotate credentials.
The configurability to control token TTLs generated from the AppRole auth method exceeds the configurability of the token auth method.
Ultimately, AppRole is a toolbox with which to build specific solutions according to individual requirements - that is why there is no single simple answer to your initial question.