Both pay the same network transmission overhead, but because scripts are unbounded user-defined work we have to move them to a dedicated thread pool (paying thread transfer costs) plus synchronization penalties to wall-clock time. In unbounded pure-CPU workloads without locking, Jython beats (pure) CPython, hands down.
Per function definition, the "compilation" work happens lazily, once per project, regardless of how many sessions/pages/views are open in that project. The trigger to bust the cache is, if I remember correctly, any change to that project that affects Perspective itself or the scripting library.
There's unavoidable overhead to marshal objects from their Java representation into a Jython representation and some other bookkeeping, but it's relatively cheap to call the same script repeatedly after it's been "compiled".
This is almost certainly a smell about something else fundamental to your design, rather than a missing capability in Ignition. That is, this in particular sounds like an XY problem, even if I am personally on board for something like a lamdba expression function. I've even gone on record as such.
Native bindings are always more efficient than expressions are always more efficient than scripts.
If you can express something using bindings or expressions, do so - not only is it more performant, it's more easily maintained, because it's harder to bake bad habits into purely declarative logic, although with Phil's toolkit it's technically possible to do more complex operations via expressions.
That OP's advice is paraphrased from advice typically given here on the forums, and only applies once you have had to reach for scripting. Again, there is nothing wrong with scripting, and it's absolutely necessary for essentially every Ignition project. But it should not be your first resort.
Once you do start using scripting, resist the siren's song of the "magic pushbutton". Extract at least the core business logic into the project library, ideally with "pure" data inputs and outputs, totally separate from any logic tied to the UI. The maximalist take some (e.g. Phil) will espouse is to never write a script in the rest of the system that's longer than a one-line call to a project library script. This gives you, for one, vastly improved version control semantics and at least some hope of external testing. In my opinion, it's a little too strongly dogmatic, but Phil's also got a lot more real world experience with Ignition than I do, so take my advice with a grain of salt.
Note that moving scripts to the project library has no real execution performance advantage nor drawback.