Maintaining SharePoint solutions without access to source code can be time consuming. Especially if you have to extract a .wsp from a farm, rename it to .cab and start looking into output files as XML feature definitions and ASPX pages.
With the evolution of SharePoint Framework, I wonder how I can maintain SPFx webparts without access to source code? Is it, or will it be possible to reverse engineer SPFx output to source code again? Preferably to TypeScript...
SPFx webparts are JavaScript so, yes, you can reverse engineer them. If you load a client-side webpart and use F12 browser tools you can see the code which is bundled into a big JavaScript file by webpack, but the webpart code is near the top and you can easily find it and breakpoint it if needed. At worst you might face minification and obfuscation.
Converting JavaScript back to TypeScript is going to be a problem, because JavaScript already is valid TypeScript. What you probably want is to get the types back and perhaps the class-like structure. For the former you are out of luck - the type information is gone. But for the latter, apparently there is a tool that semi-automates the task of getting TypeScript back from JavaScript, but I haven't tried it and I am a little sceptical about how useful it would be in practice.
If the code ships with source maps then these source maps contain the original TypeScript code. You can see this in the code of the different classes provided as a part of SPFx toolchain. Without the source maps however, you would have to rewrite all of the code to TypeScript. This might be particularly complex with release bundles which are minified.
