But what he talks is balooney. Now I wasn't directly involved with how the levels were made (they were in segments, I believe kind of like hexagonal, more likely brick style layout, with a big strip every one in a while). Every such brick or strip would get asynchronously loaded.
Okay, now how to get that fast on console? Well first, your data has to be precooked, at minimum only pointers should be fixed up. No "new"/"delete"/"malloc"/free" - you load it in a buffer, and it's almost initialized (without the pointer fixup).
Then problems - say for example Spidey goes towards one of the bricks - you should start loading the neighbouring bricks too, but as soon as you know more about where he's going you should start CANCELing these I/O requests. And better if your system really supports them (or if not so, read in less chunks, or find the buffer size that the I/O controller or OS is splitting the request into - for Xbox I think it was 128kb).
Then make sure that you get as much as possible I/O asynchronous requests per frame from the levels, sound, etc. and for a DVD (and maybe for HDD) do an elevator sort - e.g. start from somewhere and always take the next request that is closer to the previous ones (sometimes that's tricky, as by the time you want to start the next one closer, and the head is already on something further away).
Then the biggest pain is that on burn media you get one results, while on GOLD discs another. Mainly because of how CRC checksums are put - I believe it was for every 32 sectors (or 16), while on the burn was a bit different.
Then you might experience problems, where the japanese PS2 version of the console just reads badly, hopefully your devkit has the same problem, so you know you would run in to.
And not forget - check which mode would work better for you - constant angular velocity, or constant speed. In the first you get slower results in the middle (I think it was the beginning of the disk), rather than the end - somewhere (ballpark figure) 1-2mbs/s vs 3-4mb/s
And find decompression algorithm that decompresses faster than what you reading (I was able to get lzo with some small unaligned write assembly optimizations) and have uncompressed speed of 5-6mb/s instead of only highest 3-4mb/s.
So my problem with the article? He's not even talking about the simple things I explained. Believe it's that's only the scratch in making streaming game (Look what Naughty Dog did, when they could not load the level in time - the character would trip and hop - now that's very good solution, but really tied with your gameplay).
In our case, we had testers banging out what Spidey's maximum speed could be, so we can adjust the levels - some of the levels he had to do some quick missions, and pop-ups were never allowed (it was considered bug).