You need to look at the programmer's perspective.
Nor that I'm a software manager, you have to see what Square wanted and then how the programmer implemented it. Let's analaze a little about the history of what Square is doing...
The technology being employed here is called "obfuscation". It's the art of hiding data. The problem is that you can only hide the data so far before it starts to impact performance. The PSX CPU was only $5.99 from LSI. When you are spending so little on a CPU, you don't have a lot of power left over to dig data out of some obscure format.
During the development of FF7, it was discovered that direct sector access was the only way to get the performance they needed. Even though the PSX supported loading files in the BIOS, it was very slow and locked the entire system until the fire was loaded. A lot of the 1st generation games simply put a "Now Loading" screen up and let the BIOS do all the work.
Because the FF7 kernel was multitasking, it was decided that creating a threaded load routine in the game was better. The reads were still done though the BIOS via a syscall, but it was only a sector at a time and the syscall would promptly give control back to the kernel when it was done with. The other major thread was the music thread, this made sure that music played during disk accesses, so it didn't look like it was doing "nothing". Neat trick.
As evidenced, with the lack of filenames, you needed to make some kind of index so the computer wouldn't get lost. Looking at the data from FF7 you can see the process that the disk was mastered.
1) When it was time to build a disk, all the uncompressed data was preloaded in a particular data structure. I'm going to guess much like how it was on the original disk.
2) Compile-time - The executables is built, it's length is recorded. Because these can be so dynamic, my theory is there is no sector data in this file. After the compile is completed, it's length is recorded.
3) PSX data created : The ANI, TIM, RSD, HRC, and all the other PSX data is created from the source assets.
4) Compression - Pass 1 - GZIP : All the files that are not sector critical are gzipped up. The compressed and uncompressed lengths are recorded.
5) Compression - Pass 2 - LZS : Here all the files that are going to be sector critical that need LZS compression are done. After they are compressed the lengths are recoded.
6) Concatenation - Headers are made for all the files that need to be stuck together. They are then done so. Sector locations are kept blank.
7) File finalazation - All files are manifested and are in the final form that will be going on the disk, minus sector information.
Preburn - A disk image is created on a hard drive completely blank. Blank indexes are written first. Then, when a file is copied to this image, sector information is written in the files that need it, and recorded in the master index. Each file gets this treatment.
9 ) Burn - The disk is mastered.
Now that does this mean, First this meas that the files written higher up on the CD-ROM were written first, and therefore most location-critical. This means that the master index is going to be first, or last. If someone has the time, could you see the order that the filesystem was written in? (Not by time, but by sector) I bet you are going to find some interesting surprises.
By that, we can then figure out how the other Square games were authored.