If the number of recordings or monitored stations is slowing things down, it is likely from the recording solution. ASAI will handle much higher volumes and will fall apart when latency exceeds 200 ms on avg.
SSC requires call id and DS1 station to use to listen and agent station to be listened to. So, you could not camp on a station before a call as no call id would be available.
The PBX does have a limit of some 60 or so Service Observations at the same time, but this is not service observing. SSC is essentially a conference performed with a listen only path using CTI. So, any limits would be the number of simultaneous conferences and of course the number of parties on the conference.
Nice uses the alert event to determine if the call will be recorded, then starts recording on connect event. If your solution is delayed by determination of whether to record a call, perhaps delay the connect (don't use auto answer) might help? Else, the solution is just not capable of keeping up.
The SSC solution should not give a 1 second delay. Given ASAI intolerance for delays, and the relative low volume of events on your link for events on 50 stations plus some login/logout traffic from the hunts, you should expect 10-20 ms max message times on the ASAI links. There would be virtually no delay in the PBX. So, from connect event to intrusion should occur within less than 100ms unless the application is slow in making the request. 100 ms should be virtually undetectable.