El punto de ts-reset es válido, pero se queda corto. El problema real no son solo los tipos rotos de la lib estándar, sino la cultura de any silencioso. He visto equipos activar strict: true y luego llenar el código de as any para callar al compilador. Eso no es TypeScript, es JavaScript con autoengaño. La herramienta que de verdad cambia el juego es eslint-plugin-total-functions o, más agresivo, typescript-eslint con la regla no-explicit-any en modo error. Sin eso, el tsconfig más estricto es papel mojado.
Sobre el ROI en greenfield vs legacy: de acuerdo, pero hay un matiz que nadie menciona. En greenfield, el coste inicial no se diluye, se traslada al diseño de tipos. Si el equipo no tiene experiencia modelando dominios con tipos (uniones discriminadas, tipos condicionales, genéricos acotados), el time-to-first-feature se dispara. He visto proyectos nuevos en TS tardar 3 semanas en tener un CRUD funcional porque el equipo se obsesionó con el tipo perfecto para User. TypeScript no te hace mejor modelador de dominio por arte de magia.
Y sobre noUncheckedIndexedAccess: activarlo desde el día uno es correcto, pero prepárate para arr[i] devolviendo T | undefined en cada iteración. La solución no es desactivarlo, es usar for...of o .at() con comprobación explícita. Muchos equipos lo desactivan a las dos semanas porque no aguantan la fricción. Eso es un síntoma de que el código base no estaba diseñado para tipos estrictos, no de que la opción sea mala.
