I don't think your second point is restricted to Typescript at all. Every compile-to-JavaScript language I've used lets you use existing JavaScript code. Some, like Elm, make it a lot harder (really just different, but it's not plug-and-play like TS) than Typescript does but that comes with the advantage of doing so in a type safe way.

While every compile-to-JS languages enables some degree of interop, I argue that TypeScript has one of the most seamless experiences. Same import syntax, same language semantics; if there's a good .d.ts file you might not even know the difference. I was also under the impression that Flow was just a type checker and not a language, but I never really used it because I got on TypeScript early.

I think this is where we're just going to agree to disagree. I'm scared of Typescript codebases because there are so many holes in the type system it feels just as hard to refactor as JavaScript does. You still can't be sure that something claiming to be of type A isn't actually of type B.

I definitely hold the same "agree to disagree" mantra for a technology debates. There are a lot of tradeoffs and opinions, and not as much objectivity as some people pretend. But I still feel like this is a little bit of an exaggeration. I can't image having the same level of uncertainty refactoring a TypeScript application as refactoring a JavaScript application. Sure, technically an object can be anything. But I can't remember a time that has actually happened to me. I'm not saying it doesn't happen, but I am saying it is rare enough that the comparison to JavaScript refactoring is unfair.

I know you qualified that with "if you use it correctly" but I'd argue any type system that lets you ignore it completely can't be used correctly because, at some point, someone is going to sneak a change in with some dodgy type assertions and your nice typed codebase isn't safe anymore. In a personal or open-source project that probably isn't a big risk and is easy to fix at any time, but in the average workplace it's easy to miss things when there's pressure to build more features and much harder to go back and fix things that aren't visible problems.

I'm not trying to be dismissive, but I think this problem can be pretty easily solved with code standards, enforced by code review and static analysis tools. Every now and then, a bad hack might make its way into the code base due to time constraints. But if this is happening so frequently that confidence in the entire system is undermined, I think that's an organizational failure more than a technical one.

Again, I'm not trying to convince you (or anyone!) that Elm is bad. I really do like the project and I keep tabs on the development.