I think I’m at the edge of understanding what you need to know about Fn() and at the edge of my own understanding of Fn(). The situation looks to me like this:
A person orders a cake. The waiter brings the cake and says it can be eaten with a fork or with a spoon. The persons says, I do not want to eat it with a spoon. Please, I want a cake that can be eaten with a fork. Bring me another cake, that can be eaten with a fork.
Now seriously. Traditional node systems are usually restricted when you need to express something complex. They are perfect for expressions, but they struggle with procedural code (i.e. a sequence of commands). Blender’s node are for building expressions. If you need real functions, e.g. you need a node that acts as function, you have to use … closures (more info).
Now, in TSL if you can express the logic with expression, you do not need Fn(). Here is a demo where dynamic coloring is done without Fn():
https://codepen.io/boytchev/full/yyJavey
It might be somewhat fair to consider that Fn() creates a node holding the definition of a user-defined custom function. You may check the source code of Fn() in TSLCore.js to see it actually uses ShaderNode under the hood but does some additional (and unavoidable) processing of inputs.
So, if you want to convert some old procedural shader to nodes and avoid functions, convert it to expression and then to nodes.
As for the problem that some internal definitions are not exported, I have no idea whether they are not exported because it is considered they would not be useful for outside, or there is some specific reason why they should not be exported. Maybe it might be good to file a request at the GitHub Three.js repo asking for export of all internal nodes and some argumentation or usecases to show the benefit of having these nodes accessible.