Quando o aprimoramento progressivo compensa em uma aplicação que de todo modo precisa de JavaScript?

Pergunta em aberto

O aprimoramento progressivo (progressive enhancement) constrói a página em camadas: HTML que funciona por si só, CSS que melhora a apresentação e script que acrescenta comportamento. O manual de serviços do GOV.UK recomenda essa abordagem para serviços públicos. A wiki quer saber como fica a decisão em aplicações que, por natureza, não conseguem funcionar sem script, como editores, painéis (dashboards), chat e ferramentas em tempo real. Quais partes de uma aplicação assim ainda justificam uma base que funcione sem script ou com um carregamento de script parcialmente falho, e como uma equipe deve decidir com base em evidências?

Subperguntas:

• Qual parcela das visualizações de página fica sem script para um determinado público, e por quais causas: downloads que falham ou expiram em redes lentas, bloqueio por proxies ou extensões, erros de execução em navegadores antigos, script servido com o tipo MIME errado? Como medir essa parcela de forma confiável?
• A renderização no servidor com hidratação, como muitos frameworks fazem por padrão, já entrega a maior parte do benefício (primeira renderização, indexação por rastreadores, resiliência enquanto o script carrega), de modo que um caminho separado sem script acrescenta pouco?
• Quais interações têm o maior valor por linha de código de contingência (fallback)? Formulários e navegação são os candidatos habituais; arrastar e soltar ou colaboração ao vivo não são.
• Quanto custa o segundo caminho de código ao longo da vida do projeto em testes e divergência (drift), e quando esse custo é menor do que os incidentes que ele evita?
• Como agentes e rastreadores que não executam script alteram o cálculo para conteúdo que deve ser encontrável?

O que uma resposta útil contém

• Um protocolo de medição para "o script não executou" (por exemplo, um beacon dentro de um elemento noscript, combinado com uma comparação no servidor entre envios de formulário em HTML simples e envios baseados em fetch), com resultados divididos por classe de dispositivo e por rede.
• Uma regra de decisão com categorias: fallback recomendado, opcional, não compensa, cada uma com a respectiva justificativa.
• Observações de custo de pelo menos uma aplicação atrás de login, indicando a configuração do framework (renderização no servidor, hidratação, islands ou somente cliente) para que os números possam ser comparados.
• O ângulo da acessibilidade: quais fallbacks com controles nativos ajudam usuários de teclado e de leitor de tela, independentemente de script.
• Limites explícitos: quais públicos e tipos de aplicação a resposta abrange e quais não abrange.