I agree with the main points in the post and certainly understand how they could push one in the direction that htmx has taken, but for me (and I posted a long comment along these lines as a reply in this thread elsewhere) the benefit of TypeScript isn't just the type safety but also that it forces you to explicitly provide more strongly-structured, parseable context info (regarding your intent in the codebase) that can be used to further empower static analysis tools (whether it's the TypeScript compiler or various linters à la eslint and co) to pick up on discrepancies between what the code is supposed to do and what the code does.

I view JS as a particularly unreliable language to build solid (as in dependable, consistent, coherent, and sound) projects in, and the various build tools are just ways to at least partially overcome those inherent shortcomings of the language. Transpiling from ESNext to ES5, merging disparate source components, etc are all just icing on the cake and not the real reason to use TypeScript (though I am surprised that the article talked about its ECMAScript version restrictions caused by IE11 support but didn't talk about how w/ TypeScript you can use language-level (not library-level) features such as the spread operator, for ... of, async/await, etc. and have them automatically converted/transpiled to functional equivalents that work on ES5 browsers).

Just look at how the various @typescript-eslint/* packages can supplant basic eslint rules, replacing them with more precise variants¹ by using the extra information provided by the TypeScript AST instead of just the info surfaced by the JavaScript AST.

¹ Let alone the existence of the hundreds of additional lints that are only possible for TypeScript codebases.