1. Blocks dress the room; plugins run the building
Blocks, patterns, and builders excel at layout and editorial experience. They do not replace scheduled jobs, idempotent webhooks, capability matrices, or retry logic against a flaky ERP. When behavior must be deterministic and testable, that logic belongs in PHP (or a thin service layer the theme never should have carried).
2. Third-party plugins optimize for breadth, not your edge case
Marketplace plugins chase thousands of installs: extra options, compatibility shims, and feature flags you pay for in weight and surprise updates. A focused custom plugin implements exactly your workflow, drops dead code paths, and documents assumptions your team actually relies on.
3. Security and compliance want an owner
Regulators and security reviews ask who is responsible for data flows, retention, and breach response—not which brand logo sat in wp-admin. First-party code can be reviewed, pen-tested, and versioned with your release train instead of chasing a vendor’s changelog the week before Black Friday.
4. Headless and “app-like” WordPress need glue
Decoupled front ends still need authentication boundaries, custom REST or GraphQL fields, and server-side orchestration. That glue is plugin territory—kept small, namespaced, and aligned with your API contract—so the JavaScript stack does not become a second backend by accident.
5. Longevity beats novelty
Modern WordPress moves fast: interactivity APIs, block themes, performance tooling. Custom plugins that follow core APIs and avoid theme coupling upgrade more calmly than stacks built from ten overlapping “Swiss Army” extensions. The goal is not custom for its own sake—it is control without bloat.
Custom plugin development still matters because serious WordPress projects are not brochure sites with extra widgets; they are systems. The modern stack gives you better editing and delivery options—then expects you to own the parts that touch money, identity, and the law.