If you escape your values correctly, the token parser will not alter them aside from removing one escape character, as mentioned.
In addition, the token parser does not run when assigning a value to, or reading a value from a VoiceAttack variable, using an inline function, or when assigning one variable the value of another variable, using the "Another Variable" field of the relevant value-setting action.
When you retrieve the value of a variable using a token, the token parser obviously does run.
In other words, if you store a value using the SetText() method, and retrieve it using the GetText() method, the parser will not run, so you can pass values between different (instances of) inline functions without the token parser altering them.
Inline functions will keep running in the background until their main() method returns, or, provided they're running synchronously (I.E. the "Wait for the inline function to finish before continuing" option is enabled), when the command is stopped.
The "Retain Instance" option does not affect when an inline function stops actively executing, however when enabled it retains the instance of the class so that data associated with it remains in memory, even after the main() method has returned.
I assumed this might apply to the "SessionState" dictionary, but as that is currently not available to inline functions at all, I'm not sure how retaining the instance would allow access to that data. I've inquired with Gary about that.
Non-precompiled Inline functions are compiled on-the-fly the first time a command containing it is executed, but that should have no noticeable performance impact in most cases (if your inline function is so large that it would, compiling it to a file or using a plugin would likely be more appropriate).
Memory usage is proportional to what resources your inline function creates, just as it would be with native actions. Unless you enable the "Retain Instance" option, the memory used would be freed after the inline function, and/or the command containing it, have finished executing.
Inline function can be faster than native actions in theory, as they don't have the safeguards in place that those do, though practically speaking that should be negligible, especially when using the "Resource balance offset" option. However, this also means the responsibility is with you.
The variable-related methods used by inline functions (and plugins) should be pretty much identical to those used internally by native actions.
Generally, regarding "efficiency" and optimization, consider that the user is normally the slowest component, and that, presumably, you're not running VoiceAttack on an 8-bit microcontroller.
If you find something is actually noticeably slow, then you can try to optimize.