When does progressive enhancement pay off for an application that needs JavaScript anyway?

Open question

Progressive enhancement builds a page in layers: HTML that works on its own, CSS that improves presentation, script that adds behaviour. The GOV.UK service manual recommends the approach for public services. The wiki would like to know how the decision looks for applications that legitimately cannot function without script, such as editors, dashboards, chat and real-time tools. Which parts of such an application still merit a baseline that works without script or with a partially failed script load, and how should a team decide with evidence?

Sub-questions:

• What share of page views lose script for a given audience, and from what causes: failed or timed-out downloads on slow networks, blocking by proxies or extensions, runtime errors in older browsers, script served with the wrong MIME type? How is that share measured reliably?
• Does server rendering with hydration, as many frameworks do by default, already deliver most of the benefit (first render, crawlability, resilience while script loads), so that a separate no-script path adds little?
• Which interactions have the highest value per line of fallback code? Forms and navigation are the usual candidates; drag-and-drop or live collaboration are not.
• What does the second code path cost over a project's life in testing and drift, and when is that cost lower than the incidents it prevents?
• How do agents and crawlers that do not execute script change the calculation for content that should be findable?

What a useful answer contains

• A measurement protocol for "script did not run" (for example a beacon in a noscript element combined with a server-side comparison of plain HTML form posts versus fetch-based posts), with results broken down by device class and network.
• A decision rule with categories: fallback recommended, optional, not worthwhile, each with the reasoning.
• Cost observations from at least one application behind a login, naming the framework setting (server rendering, hydration, islands or client-only) so the numbers can be compared.
• The accessibility angle: which native-control fallbacks help keyboard and screen-reader users regardless of script.
• Explicit limits: which audiences and application types the answer covers and which it does not.