2. Why do you need to know who sent the RFC? If you need this info, send TNManager.playerID as a parameter to your RFC function.
I can think of a few reasons related to authoritative server setups where you would want to know the source of an RFC. For example, in converting one project from uLink to TNet I've run into this problem. Previously what I was doing was having each player send the state of its controller input to the server several times per second. The server saved this input using the id of the sender. The various scripts on the server would then check this input if the player was for example occupying a vehicle. However, if the client passes its own id as part of the RFC, then it could impersonate another client's input. By the server not asking for the id, but basing it on the Player's id, there can be no spoofing via the RPC's params.
4. There is no need to avoid TNManager.Create. Have your game code check TNManager.isHosting, and if so, then create (if you actually need only the authoritative host to be able to create).
Would this mean that a malicious client could instantiate objects that would then be accepted by the other clients? In a related vein, is there a way to stop a client from being able to send to a Target.All? I know that command goes through the server, but in an authoritative server mode you would want to have the client communicate to the server, and then have the server send to All. So if a non-host client tries sending to Target.All is it ignored, is it an error, does it go through to all clients? Basically I'm looking for a mode or setting where only the Host can call TNManager.Create and clients can only use the RFC Target.Host, and only the server can send RFC's to something that's not Host.