Hmm,
at that project/code size you get at plenty points where things matter that would be irrelevant in smaller scripts. A few years ago I extended and re-architectured a similar project, by thorough optimizations we got an speed increase of roughly tenfold, of course partially eaten up by new features.
For the beginning: rather than issuing 80 evals, for deployment I'd compile such an enormous pile of sources into a single file. For debugging, #include is much more fun.
As you mention argument passing of large xml, that's one area where ExtendScript can seriously slow down. Besides you'll probably find a size limit of about 64k for the underlying XML. We used InDesign document XML for working data, while smaller configuration data was parsed into js objects as soon as possible. I wrote a JSX abstraction layer that would work on either kind of XML.
Next problem - number of prototype slots. It definitely makes a difference if you have too much, I partitioned objects into cross-linked clusters, similar to the plugin object model (boss classes), the whole enchilada supported by an underlying framework that generated JSX collections etc. by a few declarations, roughly the equivalent to templates in other languages.
At least you're using prototypes - one really big issue with ExtendScript is the explosion of object allocations when you apply the typical closure-based JavaScript style from web programming. Eliminating them was a very big effort in our rewrite, but also gave a pretty good improvement. At least ExtendScript can produce allocation statistics, use them. Also use them to find and eliminate circular link object leaks etc. A while ago I wrote a diff utility that extends $.summary(), InDesign Server also has some goodies.
Have you noticed ESTK's profiler? Unfortunately it just gave up at our code size, probably it will also for yours. Instead I used an own profiler with several additions, e.g. I could apply the profiler selectively to some modules while already optimized modules were skipped. It really helps to know your candidates when management pressures for "quick wins" ... Where is most absolute computation time burnt, or what methods are invoked a couple 10000 times too often for your gut feeling. Again, eliminate dead code and thus reduce prototype/object slot count. When your central class has 100s properties and matching get/set methods, eliminating them one by one produces measurable improvements.
Of course I also tracked down some offending statements where the same value was assigned over and over again causing severe text recomposition while nothing was actually changed ... You can only find such problems with exact measurements.
Other areas of fun: under the hood (at C++ level) every temporary text expression is backed by an enormous aggregation "suite", there are many things you can do wrong there. For example these things just pile up and are rarely purged, therefor it has become common wisdom to do an occasional save() for lengthy scripts.
Again at the XML side: if you do severe document XML (we did), there are some circumstances where text attributes will get lost/ignored. There are ways to speed up expressions underlying references to document XML, and so forth. To know when to rebuild the XML expressions or when they can be reused is a science for itself. Same goes for other objects, as you already mention getElements(). Sometimes it helps, sometimes it is just a waste of execution time.
As you mention the advantage of SSDs: How frequently do you dump those jsx sources into ExtendScript? If you currently use the "main" session (is that possible for HTML extensions at all?), utilize persistent sessions instead - when you have eliminated your object leaks.
There are plenty more optimizations, I probably should write a book - to be sold in about 5 copies. Unfortunately the strongest advice in its preface would be to not use ExtendScript/JavaScript at all for large scale projects, because they turn into a maintenance nightmare where other languages catch errors on compile time. Dependent on client preference I'd probably turn to Java or do the whole thing in C++, at increasing code size development speed will be roughly on par.