There shouldn’t be any limit on the number of form objects other than available memory, and form objects are small enough that I would think it would be impossible to come anywhere near exhausting available memory. As you add more objects Panorama should get slightly slower, but there is no reason there should be a break point where suddenly it gets a lot slower, or conversely, where it gets a lot faster as objects are deleted. It sounds like maybe you had a particular object that was corrupted somehow and deleting that object cleared up the delay.
the Force Quit Applications window showed Panorama not responding
Normally any application is constantly checking to see if the mouse has been clicked or a key pressed. But if the application has a long task to perform, it will temporarily stop these checks. When it does that for more than a few seconds, Activity Monitor and Force Quit will say that it is not responding, and the cursor changes to a ranbow. That usually just means that it is very busy and doesn’t have time to do the checks. When the task is finished, the application will resume the mouse & keyboard checks and everything gets back to normal. Ideally you write programs to avoid this kind of long task, but it’s not always possible.
Of course if a program has a bug it could actually just be looping continuously and not actually making any progress toward finishing. There’s really no way to tell the difference between an actively progressing task and a hang like this other than waiting a while.
If I know a task is likely to take a long time, I’ll add a progress indicator. However, something like selecting objects is not ever expected to take that much time, so it doesn’t have a progress indicator. (Adding a progress indicator is quite a bit of work and will actually slow down progress a little bit.) In some cases the long delay is in Apple’s code, not mine, so there is no way to indicate progress.