Just as with as with any transpiler, you never have 100% confidence in your source maps, especially if you mix and match your tooling.
And you almost always loose some part of native debugger functionality in browser or node. I never ever saw a transpiler that does not break correct display of properties along the prototype chain or breakpoints inside constructor functions.
This is where vanilla es6 blows everything away. I know not so few dotcom tier companies with 1m+ per hour websites which stick with handwritten JS on the frontend solely because of that: productivity gains for them simply not worth losing few percents of visitors because of hard to catch and debug bugs.
It's not like we're compiling Haskell to JavaScript, I've never had trouble debugging because of differences between TypeScript and my build output. I honestly don't even think about it.
Also remember that TypeScript is very forgiving if you decide to avoid types in some part of your codebase. However, I will tell you that I always end up regretting not using types when I come back to the code in 6 months.
> Library authors opting for TS may well be closing door for contributors from mainstream dev demographic.
I think it's the complete opposite. Good typings make it easier for new contributors to get up to speed, make changes without breaking anything, and document those changes. Furthermore, it makes it significantly easier to push out new versions of your libraries since TypeScript will help users debug breaking changes.