Decoupled architecture, in a WordPress context, is the deliberate separation of where content is authored from where it's delivered. WordPress runs as the editing tool, but the public site is rendered by a separate front-end — usually a static-site generator like Next.js or Astro, or a JavaScript framework served from its own infrastructure. Content moves between the two layers via the WordPress REST API or a GraphQL endpoint.
I choose decoupling when a project has one of three needs: a front-end design that's fighting the WordPress theme system more than it's using it, a content team that needs to publish to multiple destinations (web, app, email, signage) from one source, or scale where the cost of running PHP per request stops being defensible. Decoupling solves the first cleanly, the second well, and the third for a narrower set of sites than the marketing usually suggests.
The trade-off is operational complexity. A decoupled site is two systems instead of one — two deploys, two sets of logs, two security surfaces, two places where something can break. Live previews, scheduled publishing, and many SEO plugins assume the WordPress front-end exists; in a decoupled setup, each of those becomes a small project of its own.
For most WordPress sites I work on, full decoupling is overkill and a fast traditional setup with edge caching gets you 90% of the perceived benefit. Where decoupling earns its keep is on large editorial sites, multi-channel publishing, or sites with a custom front-end that genuinely doesn't fit the theme model.