The limiting size of a project, as far as the number of blocks and components is concerned, is what goes on a specific screen. Basically, the limit applies to each individual screen, but not readily to the overall application; hence you can offset some of the size to other screens, with a premium to pay because you have to co-ordinate the opening and closing of those other screens and manage the information being transferred between them.
However, if your application is numerically intense, then you the processing is slowed down by the inherent nature of the environment, which is more of a interpreted language than a compiled one.
On the same device, a program will run about 9 times faster if it was written in Python – leaving you with the burden of figuring how to interface your Classic component with a Python module.
With Java, it would be massively faster still, and how to interface should be covered in many tutorials since this is exactly what extensions are about.
Right now, the API 28 compiler is defective, unable to handle a project larger than 1/3 the size the API 26 could accept. That is a major issue since API 28 has been mandatory since August 2019; and Thunkable has been promising fixing it for months while announcing that all support for Classic will be terminated withing the next 6 months. My suggestion is that your move your business to Kodular.