It's not either/or — it's global as the foundation, scoped overrides as the exception. The mechanism that makes both work cleanly is CSS custom properties (design tokens).

Global theming — the base layer

Define your design tokens once on the root:

:root {
  --color-bg: #fff;
  --color-text: #111;
  --color-primary: #2563eb;
  --space-md: 16px;
}
[data-theme="dark"] { --color-bg: #111; --color-text: #eee; }

Every component consumes tokens (background: var(--color-bg)). Switching the theme flips a root attribute — the whole app updates with no re-renders.

Scoped / per-component theming — layered on top

Because custom properties cascade and can be redefined on any element, a subtree can override tokens locally:

.promo-section {
  --color-bg: #1a1a2e;   /* this section is always dark */
  --color-primary: gold;
}

Everything inside .promo-section automatically re-themes — no prop drilling, no separate theme system. Same for a "danger" zone, a marketing banner, an embedded widget, or a component that ships its own theme prop.

When you actually need per-component theming

• A always-dark section inside a light app (or vice versa).
• A reusable component library where consumers pass a theme/variant.
• White-label / multi-tenant: a subtree branded per tenant.
• A/B-tested or campaign-specific UI.

Why not make everything per-component?

• Consistency — a global system is what enforces a coherent look. Per-component theming everywhere = drift and chaos.
• Maintainability — one place to change the brand color, not 200.
• Performance — token-based theming is one attribute flip; scattered JS theming per component causes re-renders.

Implementation note

CSS custom properties handle ~all of this natively. CSS-in-JS ThemeProviders (styled-components, Emotion) can nest for scoped themes too, but they re-render React subtrees on theme change — custom properties don't. Prefer tokens; use a ThemeProvider mainly to expose tokens to JS if needed.