If memory use is your prime concern, then lots of little (low vertex count) features is probably going to be more to your liking than a few very large (high vertex count) features. But you may find that "too many features" may eventually overwhelm even "too many vertices" for processing speed.
If you think about how the algorithms must be structured to process all features against all features between two feature classes, you're working with multiply-nested loops (for features in FC1 and FC2, and for the vertices in Feature1 and Feature2). In operations like drawing, the number of draw requests is of often greater concern than the vertices in each request, but with theme-on-theme operations, the key algorithms are likely to be based on the counts of vertices in each F1/F2 pair, with a "big O notation" of "O(N*M)" (the time to complete the operation is related to the factor of the number of vertices involved), which, for large features in both datasets, is close enough to O(N^2) to make you worry about the job ever completing.
I've had success by overlaying massive features (like Russia, Canada, US, Australia, Brazil, Norway) with a 5 degree grid (fishnet) to reduce feature complexity for intermediate processing. I've seen point-in-polygon operations on a vertex-restricted 1:15m COUNTRIES layer run 100-1000 times faster than the original table (with only a 20x feature count increase). You do need to be careful in your processing logic to handle one-to-many and many-to-many relationships correctly though, especially in cases where a false boundary exists.
There's also a "diminishing returns" aspect to the savings of working with smaller features -- I settled on a 5-degree grid by testing performance of intersecting with 90, 45, 30, 20, 15, 10, 5, 3, 2 and 1-degree grids, which showed an alarming increase in processing time as the number of total features ballooned.
There are times where fewer features with more vertices are more efficient, so it is probably worth the effort to do some testing on order of operation with real data (not simplified test subsets) before committing to one approach over the other (balancing RAM utilization with run time).
NOTE: I re-ran the gridding exercise with modern hardware, and got optimal performance with a 30-degree overlay, so that increases the risk of too-small features, and increases the importance of evaluation with production data.