When are scratch orgs the right choice, and when are they not?

Scratch orgs are right when development is genuinely source-driven. The org's shape comes from a definition file, its metadata comes from the repository and its data comes from a seeding script, so it can be created and destroyed on demand. That makes them excellent for isolated feature work and for spinning up a clean environment per pull request in continuous integration.

They are the wrong choice when the org's metadata is not fully in source, because whatever is missing from the repository is simply absent from the scratch org and the developer discovers it the hard way. They are also wrong for user acceptance testing and for anything needing production-like configuration or data, because a scratch org is built rather than copied.

Two practical constraints I raise early: scratch orgs require a Dev Hub and consume its allocation, and they are ephemeral by design with a maximum lifespan, so nothing that matters can live only in one.

In practice I usually end up with a mixed strategy — scratch orgs for feature development and CI, sandboxes for integration, UAT and staging — and I would rather defend that than claim an org is more source-driven than it is.