I managed to find what looks like the original Developer Documentation of the toolchain, which was hugely helpful to piece the puzzle together.
To answer my own question: Yes, there was a standard, though it looked very different from later CD-ROM formats and more like a magnetic tape format, and it's pretty much all manually managed.
The CD-ROM² unit came with a System Card (*1), which provided BIOS functions to interact with the CD. All games that were made using the system card (*2) and official tool chain follow a similar structure. There are different versions, but the differences don't matter here (*3).
On the final CD, there is a Header ("IPL") to load and run the initial executable, but there is NO central directory - a game would literally hardcode sector addresses into its code and say "Read X bytes from Sector Y into RAM Address Z", and the toolchain would be used to lay out that structure. (*5) Technically, you can lay out the CD however you want apart from that IPL header, but it seems that all official games followed the structure created by the official toolchain.
The Hu7 dev kit came with a 620 MB Hard Drive (*6), and the idea was to declare "I have a file named test.bin that's at most 8 blocks long", which would reserve 8 Blocks * 2048 Bytes = 16384 Bytes for a file, and then the developer could later update the actual content of the file. If the actual file is less than 16384 Bytes, it would be filled with 0x00. If the actual file is more... well, tough. You'd either have to reserve a new file at the end, or backup the entire hard drive to tape and restore only the used files as a kind of manual defrag process.
When you're done with the layout and ready to write game code, the INFGET.EXE in the toolchain would create an Assembly file (they call it an "equ file" because it's all just definitions like TESTBIN_LW EQU $0001) that contained the actual sector offsets of each file. Audio Tracks were also handled through this, though they used different commands.
BIOS functions like CD_READ/CD_SEEK/CD_EXEC take three arguments, REC H, REC M, and REC L, which could be fed from those definitions (TESTBIN_LW would contain the REC M and REC L bytes, while TESTBIN_HI would contain the REC H byte).
So the "block reservation" strategy made sense because you have a chicken/egg problem: How can you compile your application with all the hardcoded offsets if you don't know yet how big the resulting executable is and where it's located? You did that by reserving the space/location beforehand - it's all completely laid out by hand, and then the actual content is filled in later.
There is no need for the data track to be Track 2 - it can be Track 1, which some homebrew games do (*7). The System Card BIOS will seek to the first data track and read the IPL header from there. But I assume it made so much more sense to have Track 1 be the "Warning: Do not play in a CD Player" audio track (*8), and because the official toolchain/documentation does that, all official games do that.
The BIOS supports a second data track (the CD_BASE function supports two offsets), though I don't know if there was an official intended use-case for the second data track.
I've seen a few possible explanations, and the one that makes most sense to me is for performance. By placing the second data track at the end, it's located more toward the outer edges of the actual CD. The 1X Speed CD-ROM drive was pretty slow, and data toward the outer edges reads a bit faster (better latency/lower seek times?), so it looks like it's good to place media assets there. That said, I haven't spend too much time looking at what's actually on there on the games that I own.
I found an alternative explanation that data would be duplicated on both tracks in case of scratches making stuff unreadable in one data track - but I couldn't substantiate that claim and I'm not seeing that duplication on the games I own, so I assume that's just a homebrew thing.
(*1) The card was built directly into some later systems like the Turbo Duo
(*2) There was at least one unlicensed CD Card, and the few games seem to have a different disc format. I don't care about this one.
(*3) Version 2.0 added CD+G support, Version 2.1 added some way to auto-detect disc changes. The Super CD-ROM² (3.0) (*4) and Arcade Card added more RAM. But the disc format stayed the same.
(*4) The Super CD-ROM² is not to be confused with the SuperGrafx, which was a different console, which didn't have a CD-ROM drive. Well, unless you add one yourself.
(*5) There is a differentiation between Audio Tracks and Data, and different BIOS functions. But even audio tracks have to be hardcoded with offsets in the application. Also, it's not really sector addresses: One would specify a base address using CD_BASE and then a record offset when calling CD_READ, and the BIOS itself would do the "CD_BASE + (Offset * 2048)" math. Also, even though the Hu7 SDK has tools to maintain a central directory on the development hard drive, it looks like the final CD doesn't even contain the original file names anymore - the central directory only exists as definitions in an Assembly file, compiled into the executable.
(*6) And also a 8mm Tape Drive, which could be used for backups but also as the final master - NEC wanted you to send them two tapes with your CD-ROM image so they could duplicate it. Ah, the era before CD-Rs or sending a hard drive with a binary fine were an option.
(*7) Nowadays, HuC and related tools like isolink seems to be the toolchain of choice, which doesn't strictly follow the same methods as the Hu7 dev kit tools do
(*8) Yellow Book compliance is definitely not a thing here, even though that standard came out in 1983. I think NEC made the right call here: CDs were still very new technology, the PC-Engine was one of the first systems that used Data CDs, so it's reasonable to assume that people would put the CDs into a regular CD Player.
