IME, dynamic secrets don't scale well. First, you're going to have a tough challenge getting a large org to stop sharing secrets amongst apps/hosts. Tougher still is providing a justification for why host1 for Salesforce needs a unique credential from host2 for Salesforce that is doing the same thing. Second, ensuring privilege creep doesn't occur becomes nightmarish when you consider an environment today that has 500k secrets and having to audit the authorizations an ID was granted in multiple backend authentication systems after that ID has been deleted. Finally, generating dynamic ids for an environment like this is a staggering amount of compute workload. Taking that same 500k environment and breaking these out to unique credentials dynamically generated puts you into 7 figure numbers pretty quick. Even if we ignore the complexity of such an arrangement, just consider what the performance demands are going to be to generate an id, assign it privileges and a password, provide that to a client, then clean the same id up later. We'll ignore how this looks in an environment where you have to replicate the identity that was created across multiple authenticating backends. (think Active Directory domain replication)

In short, I think dynamic secrets will increase the threat surface dramatically, while simultaneously increasing complexity. Complex systems are expensive to maintain, hard to secure and notoriously fragile. There is a limited scope use case where dynamic secrets may be a good fit, but I for one wouldn't base a purchasing decision on whether or not my secret store can do dynamic secrets. Instead, I'd want a secret store that has some provision for secrets rotation that I can tailor to the needs of my specific use cases.