Bindings, throughout Ignition user interfaces, deliver values to session/view/window/page properties, custom or otherwise. All bindings are "set up" when a Perspective view or subview or Vision window or template is opened. The setup yields a java collection of objects tightly integrated with each other and with the target component. With the exception of any jython involved, everything is effectively pre-compiled during setup. Information flows from element to element in handsfuls of microseconds or less.
While some bindings are "once and done", like expression bindings that yield constants, or non-polling queries, most bindings are intended to monitor some source of data and deliver updates through the binding. When a source reports a change, the binding completely re-executes.
Transforms are a Perspective-only enhancement to bindings that create a chain of consecutive operations, with one result feeding the next, with the final operation's result providing the value for the target property. {Perspective desperately needed transforms because its complex components' architectures have a severe "impedance mismatch" with Ignition's internal object types, particularly dataset objects.} Transforms, for some unclear reason, introduce substantial overhead, on the order of high tens to low hundreds of microseconds.
Jython, meanwhile, whether invoked in a binding by runScript() or by a script transform, adds considerable additional overhead. Again, tens to hundreds of microseconds per invocation, plus the performance penalty of an interpreted language.
For some timing comparisons between script transforms and pure expressions for some common Perspective UI tasks, look at my Integration Toolkit module's topic for some of the testing shown there:
For some benchmarks on transform overhead versus runScript versus no script at all, check out this topic: