When it comes to performance, I have found are that flex repeaters function the most reliably when used with a fixed-size array of objects for the instances property. When it comes down to updating the instances, writing to the elements of this “fixed” array produces reliable results. I have also had better results with bindings on array element object members, but that is tedium at its peak.
The nature of flex repeaters implies that it is an expensive operation to change the size of the array, as it has to destroy/create views during runtime. It seems to be ideal if the view can start with a fixed number of views that start / load without waiting for a binding to evaluate. Of course, when you do evaluate your particular queries/processing/etc, all perspective will be doing is updating existing views properties - which is much more efficient. If you however need to get data or state back out of these “child” views, you’ll have to use perspective messages to get data or state back to the parent view.
The downside is that the repeated view must have control of whether or not it is visible, depending on how many points of information you are trying to display. I feel like that is a reasonable tradeoff for better performance.
It looks like with your application that there is an upper limit of the view you will repeat, so I figured I would mention this.