Your argument is based on vertex work being the performance bottleneck in Prime 2 (or games in general if you prefer). I don't think that's such a safe bet.
of course, it's a subject to speculation. but i still deem this particular one viable.
Geometry (and while we're at it: texture quality) in Gamecube games is IMO much more limited by the small memory than by Flipper's performance.
aside from geometry per se not being that memory intensive*, i thought flipper provided these nice integer vertex compression formats (i.e. in addition to the fp32), which, if not universally applicable, would still allow wary devs as retro to halve the footprint of the better part of their geometry assets. i'm basing this on the fact that the metroids seem to predominantly use visuals akin to vertext formats as simple as position+normal+2 uv sets - i.e. i'm leaving aside skinned scene content, which by all means is used sparingly in the mp series.
now, if i did not screw up a calc in that 1st footnote below, and we subsequently factor in the abovementioned compression, that still leaves ~8MB worth of texture space**. or IOW, retro could have used as much as ~16MB worh of geometry at every single moment, while utilizing flipper's TnL power practically to the max!
now, call me an optimistic simplificator, but i don't see the above scenario as
that improbable. if anybody, retro could have really pulled off that one.
(that's not supposed to mean you're totally wrong; I expect at least a 3x jump in graphics performance myself, but your argument just isn't convincing IMO)
oh come on, my cat bought it ; )
* assuming flipper's 6M-to-12M tris/sec attested TnL performance with fully-lit and textured meshes, @60FPS = 100K-200K triangles per scene, with index-less formats (strips, fans) that would amout to similar amount of vertices, with a reasonable vertex format of position+normal+2*uv = 10 scalars/vertex, using fp32 as scalars = 40bytes/vertex, grand total of 200K*40bytes = 8000KB worth of geometry you may hope to push per scene at these assumed conditions, while not being clever with any vertex compression schemes. throw in the fact that metroids level topology constitutes of individual rooms (rooms being separated by retro's trademark portal & streaming tech), and mp rooms have
usually high scene visibiliy, i.e. low intra-room occlusion factors, or at lest not so much that you could use in-advance mass scene content rejection, and you end up with not more than a couple of scenes-worth of geometry assets per your average mp room. provide for some double-buffering for the streaming algorithms, and we end up with ~32MB of geometry assets you may want to have
at max at any single moment of your average mp gameplay. take this as an absolute upper bound.
** flipper's on-board tex pool non-withstanding, and assuming sound assets being kept in eveybody's favourite A-ram.