It's rarely useful to compare software written for such disparate platforms; even if it's the same game, it's not technically the same game since PS2 and OG Box had only fleeting similarities (like, both had a CPU, both had a 3D graphics processor, that sort of thing.) All of it differed vastly though, on a high level philosophical/implementation level and on a low level programming/technical level. You had to reprogram a PS2 game completely from the ground up for the Box, and the other way around, and not just because the Box had almost twice the RAM of PS2 either (which is ordinarily a big limitation for 3D games.)
If you ported from Xbox to PS2, you had to basically retool your entire game to account for half the RAM, a CPU with no cache, fewer or even no parallel execution units and no speculative execution (which means big hit in execution speed of complex code). Then there's the whole fullblown GPU versus dumb rasterizer hardware where graphics is concerned...
As for the GS/NV2A debate, the only genuine advantage GS had was in brute fillrate. It had no modern features, and even lacked some fundamental ones, like a full set of alpha blending modes or a working MIP mapping implementation, which again frustrated things for programmers. It could only access its own 4MB of on-chip memory, and had to be served data through a connection to the rest of the system which could bottleneck unless you took some care to prevent it (again adding to the quirkiness of the whole platform.)
NV2A on the other hand had a modern, beyond DX8 feature set including pixel and vertex shaders, robust texture compression, and could access the full 64MB of RAM in the system. It didn't have the brutish fillrate/video memory bandwidth of GS though, which meant that you needed to take care and not draw unnecessary stuff or you'd run out of memory bandwidth (particularly when rendering transparent pixels as that gobbles twice the bandwidth due to read-modify-write requirements), whereas with PS2, drawing unnecessary stuff was typically, and paradoxically, The Way to get things done as quickly as possible*... You also had sufficient on-chip bandwidth to do full speed transparencies with basically no speed penalty.
So it's totally different schools of hardware design. Like asking, oil painting versus stone sculpture - which is best? It doesn't really make sense asking such a question.
*Without making too long a story out of it - typically drawing pixels is a big consumer of memory bandwidth so you want to draw as few pixels as possible, so you prefer to draw front to back as much as possible and use Z-buffer to avoid drawing invisible pixels. However, GS has on-chip memory divided into separate banks with total of over 1500 bits bus width to said banks meaning massive bandwidth, but only a small amount of free video memory space left after allocating space for your screen and Z buffers, and a narrow pipe between video memory to main RAM, so you can't fit all the textures a typical game uses. And GS can't texture from main RAM either, you must store textures in video memory. So because of the slow pipe to main RAM, you stream in your textures sequentially once per frame and once only, and draw all polygons which use that texture, regardless of where those polygons are on screen or if they will later be covered by something else. GS has plenty fillrate to spare anyway in just about every conceivable situation. The opposite basically of what you'd want to do on any other 3D rendering hardware.
If you ported from Xbox to PS2, you had to basically retool your entire game to account for half the RAM, a CPU with no cache, fewer or even no parallel execution units and no speculative execution (which means big hit in execution speed of complex code). Then there's the whole fullblown GPU versus dumb rasterizer hardware where graphics is concerned...
As for the GS/NV2A debate, the only genuine advantage GS had was in brute fillrate. It had no modern features, and even lacked some fundamental ones, like a full set of alpha blending modes or a working MIP mapping implementation, which again frustrated things for programmers. It could only access its own 4MB of on-chip memory, and had to be served data through a connection to the rest of the system which could bottleneck unless you took some care to prevent it (again adding to the quirkiness of the whole platform.)
NV2A on the other hand had a modern, beyond DX8 feature set including pixel and vertex shaders, robust texture compression, and could access the full 64MB of RAM in the system. It didn't have the brutish fillrate/video memory bandwidth of GS though, which meant that you needed to take care and not draw unnecessary stuff or you'd run out of memory bandwidth (particularly when rendering transparent pixels as that gobbles twice the bandwidth due to read-modify-write requirements), whereas with PS2, drawing unnecessary stuff was typically, and paradoxically, The Way to get things done as quickly as possible*... You also had sufficient on-chip bandwidth to do full speed transparencies with basically no speed penalty.
So it's totally different schools of hardware design. Like asking, oil painting versus stone sculpture - which is best? It doesn't really make sense asking such a question.
*Without making too long a story out of it - typically drawing pixels is a big consumer of memory bandwidth so you want to draw as few pixels as possible, so you prefer to draw front to back as much as possible and use Z-buffer to avoid drawing invisible pixels. However, GS has on-chip memory divided into separate banks with total of over 1500 bits bus width to said banks meaning massive bandwidth, but only a small amount of free video memory space left after allocating space for your screen and Z buffers, and a narrow pipe between video memory to main RAM, so you can't fit all the textures a typical game uses. And GS can't texture from main RAM either, you must store textures in video memory. So because of the slow pipe to main RAM, you stream in your textures sequentially once per frame and once only, and draw all polygons which use that texture, regardless of where those polygons are on screen or if they will later be covered by something else. GS has plenty fillrate to spare anyway in just about every conceivable situation. The opposite basically of what you'd want to do on any other 3D rendering hardware.