Z-Buffer had huge bandwidth impact that's true, but you can deal with it depending on you game. A good example is SSB which use Z-Buffer only for characters, all the rest is build from bottom to top. Combine this with the fact it only use "one cycle" graphic computation (N64 allow to do another shading computation pass in a mode call "2 cycles"). This allow big framerate.
> most games implemented their own pseudo z-buffer in microcode.
Just two or three IIRC. Mainly Factor 5 games.
Goldeneye use Z-Buffer, bullet texture overlaps because the poly offset value used to apply bullet texture on walls is always the same.
> The general theme of the technical analysis was that the N64 had a lot of "features" that had a massive performance impact to use, so many of them went unused.
I wouldn't say that.
1) The N64 is a complex console. It still inherit the "all electric" tradition of 16/32 bits consoles but focusing on 3d computation and shading so it need skilled peoples and time to do interesting things with it (in its last days, N64 had very impressive games).
2) With that, Nintendo devs provides GBI (graphic binary interface) which was not such efficient on the vector computation side (but generic enough to allow peoples to use it).
3) N64 had a all-wired per pixel processing unite (a GPU named RDP), meaning it could provide high quality pixels like never before but this was costly.
4) Because texture had to be stored physically "inside" the RDP chip for efficient processing (remember, 3DFX didn't even exists at this time and the GPU word was a concept), memory cost (and, I suppose, size limitation) were important so they choosed to focus on pixel quality over texture definition (there is actually many hack to "visually" improve texture definition: http://imgur.com/2EeH5Yg).