Since we are talking about the source code, I’m sure someone much more knowledgeable than me might be reading and could maybe confirm or deny the rumor.
The only real cause for lag in SM64 is that the RDP graphics chip has a fixed rate for how many pixels it can draw per frame, and that's quickly filled up by large triangles, transparency, any 2-cycle effects like fog, overdraw, etc. (and that's not even taking texture loading latency into account)
* Tris are sorted by whether they are static (level geometry) or dynamic (moving platforms). So only dynamic tris need to be reinitialized every frame.
* Tris are further sorted into which cells they touch. A cell is a spatial partition of a level. So collision detection only needs to check against tris in your current cell.
* Tris are further sorted into walls, floors, and ceilings (depending on their normal). The find_wall_collisions, find_floor_collisions, etc. functions are each optimized for that particular kind of tri.
* Tris extend their hitbox along a coordinate axis (the up axis for floors/ceilings, the one closest to their normal for walls), instead of along the normal itself. This is cheaper to test, since you can just project down along that axis and it becomes a point-in-tri test in 2D.
Even with the strange FPU/ALU combo that NEC did, you can get away with a lot on the CPU side.
Example: he claimed in [1] that a Nintendo leak contained "the entire source code of IOS" (IOS being the Wii operating system) and "the Verilog for the entire Nintendo Wii". Both of these claims are completely wrong and have been refuted by both console hackers and emulator developers for the Wii. I told MVG on Twitter, he replied saying approx. "oh it's not my fault I just read what was written online and haven't looked at the details myself" [2]. To this day the video is still up, there is no errata either in the description or in comments. This is not the only example, just the freshest one in mind and one I was directly involved with.
[1] https://www.youtube.com/watch?v=n8G7eq0GlQs [2] https://twitter.com/ModernVintageG/status/125820871313715200...
Well, in this video it's not like he's stating it as absolute fact that they didn't forget to use -O2. He just presents another much more plausible (IMO) explanation. And he backs it up with direct references to original documentation and a tweet from a developer experienced with early N64 development.
I think his claims here looks pretty solid, if you have reason to doubt them based on the content of the video, it'd be nice if you shared that.
More examples would be interesting too if you can remember other cases. To me, getting a fact like that wrong on a breaking news kind of video and not taking the time to correct it later isn't that big of a deal to be honest. If it was really important to me what the content of the leak was I'd check myself.
Anyone who has experience working on emulation and reverse engineering of Nintendo games can tell you that Nintendo keeps doing basic technical mistakes when shipping production games. Dolphin's wiki has a whole category for "games that shipped with debug symbols". Pikmin has a freakin' mostly-working PC port of an early version of the game on the GameCube disc. There's also no evidence that other N64 launch titles had the same idiosyncrasy of compiling in -O0, and the whole SDK is compiled in -O2 as he even mentions in his video. How does that fit with the "early toolchain" line of reasoning?
TL;DR: Actually forgetting to build with optimizations enabled is completely in line with what emulation developers and game reverse engineers have seen from Nintendo in the past 20 years. MVG just states his own theory as fact, without the Nintendo console hacking / RE / emulation experience, and with very little evidence which doesn't even match his own claims.
EDIT: See also [1] hidden in the 2nd page of YT comments on that SM64 video, from someone who was involved with the SM64 decompilation project.
TL;DW: O2 was causing problems in the first version of the SDK, but all other libraries (libUltra) were compiled with O2.
Nintendo didn't "forgot" anything, they just have to. Same as other stories (DK64 bug that force Rare to ship DK64 with expansion pak).
CC_FLAGS = -fno-pic -mcpu=4300 -nostdinc -I$(ROOT)/usr/include -I$(ROOT)/usr/include/PR -c -O2 -G 0