Understanding how the drivers work may help answer this. When you set the PollRateOverride on a driver instance, it only applies to subscriptions and it is a target rate because the communication is what limits most things. Take for instance you have a serial communication link at 1200 baud. Then you add a driver and set the PollRateOverride to 10ms. Obviously the software will not be able to refresh your subscriptions at a rate of 10ms when the round trip read may take 100ms.
Now let's add 2 BasicLabels, one with an address of 40001 and the other 40101. It will take the driver 2 separate reads to refresh both BasicLabels. If each read takes 100ms, then the screen refresh rate will be 200ms, no where near the 10ms put in PollRateOverride.
We now modify the BasicLabels to use addresses 40001 and 40002. The driver optimization now comes into play. The driver will perform this with a single read, parse the values, then send the appropriate values to each BasicLabel. So now we have 2 BasicLabels on the form, but our refresh rate is now 100ms instead of 200ms.
Since the driver is set to 10ms poll rate, but the communication bottleneck does not allow this, there is no "down time". As soon as the driver receives the data, it immediately initiates another read. This all happens on a continuously running background thread. If that thread has no sleep time, it begins to use more CPU time. If running on a less powerful PC, you may start to see an increase in CPU usage, which in turn may begin to decrease the response to user input.
I do very little work with Modbus, so I don't have any real figures to post. But I do a lot of work with the ControlLogix driver. I have tests with 5 BasicLabels all pointing to various tags that are not in an array. I set the PollRateOverride to 0 just to make it refresh as fast as possible. On my laptop, it acheives an average refresh rate of 5ms over a wireless Ethernet connection. Running this same app on a PC with an Atom processor at 1.8Ghz will use 10% CPU and not show any noticeable effect on user input response.
All of my apps that I develop typically have 10 or less forms and typically less than 15 items on each screen, so I can't speak for very large applications. But I have assistants users that have used hundreds of controls on a form. Not too long ago someone posted on here stating they had 600 DigitalPanelMeters on one form.
The short response is that there is no limitations built into the software, but only limitations created by hardware bottlenecks.
