Scalability depends on hardware, software version and usage pattern and can vary considerably.  See the 'scalability' white papers here: http://developer.cisco.com/web/jtapi/docs.  Note that the 
 

 
UCM must create an internal 'station' object (memory/CPU) whenever a device must be monitored for events.  For JTAPI this means adding a terminal or address observer.

 
 
This should impact only the local JTAPI client, and will not consume additional UCM CTI resources once the device is already open
 

 
Any observer that ends up receiving events from the device requires a station object for the device on UCM.  So terminal observer or address observer will consume a CTI resource.  Note that once the device is open - say, for terminal observer - adding an address observer does not usually consume a CTI resource, as the device is already 'open'.  See the scalability docs for details, as a device with many addresses will at some point consume an additional resource.
 
Beyond this, in later UCM versions efficiencies have improved scalability in certain scenarios, so that things like observing the same device with multiple CTI clients can be 'free', etc.  The CTI resource/scalability mechanism is intended to provide guidance around performance impact, it's not an exact science nor is it strictly enforced by UCM.  The main authority for calculating overall CTI impact on a cluster wll be the UC Capacity Tool (see the scalability docs for details) - this is what sales teams and TAC will use to design or support customer installations.

Apparently load-balancing across CTI-Managers is not necessary and there is no real facility for this (at least without sacrificing failover, as you suggest.)