Managing a secret well versus not needing one
A traditional service account relies on a static, long-lived credential — generated once, distributed to wherever the software runs, stored securely, and eventually rotated by hand on some schedule. Every step in that lifecycle is a place the credential could leak: from source control, from a build artifact, from a configuration file that ends up somewhere it shouldn't. Managing this well is possible, but it's an ongoing operational burden that never fully goes away as long as the credential exists.
A workload identity takes a different approach: the platform a piece of software is actually running on issues it an identity dynamically, based on facts the platform can verify directly — which container image is running, which deployment it belongs to — rather than the workload carrying an embedded secret at all. There's nothing to leak from configuration or source control, because nothing was ever placed there to leak.
Where the older pattern still has a place
Workload identity depends on the underlying platform actually supporting it, which not every environment does — a service running somewhere that can't issue or verify a workload identity still needs a credential of some kind, which means the service-account pattern, managed as carefully as possible, remains the practical choice there. The broader shift is toward workload identity wherever the platform makes it available, since it removes an entire category of credential-management burden rather than merely making that burden more manageable.