And once you have a project with a fixed amount of ROM, either because the hardware is at a point in its life cycle where you can’t change it, or it’s third-party hardware and you have to use what you get, or because you’re already at your BoM budget, then your software will behave like an ideal gas - it will expand to fill the available ROM. This happens because until you run out of ROM, you will write your software in whatever way is easiest to get your job done. But then once you run out of ROM, you will go back and look for something that you can make smaller. Then you can add a few more features or whatever, until you run out of space again. This process will repeat until you’re done, but your ROM will always be nearly full.
I’ve tried to use this analogy to PM’s who have trouble understanding why adding more engineers to a project doesn’t make it go faster: the software expands to fill its container.
https://tcrf.net/Category:Games_with_uncompiled_source_code
It's usually more common on CD games with the directory/file being unlisted, but it's always interesting to find partial source code bakes into ROMs. Last I heard/understood, it was usually as some sort of white space padding; in the case of CD-ROMs and an artifact of the sector-copying mechanism in disk duplicators.
Also, the bytes cost money, but if you have a 32K ROM (because the next lowest size is 16K) and only 28K of data, it's not costing anything extra to fill that space.
a time when literally every byte cost money
Every chip cost money, right? If your game shipped on a single 1mbit EEPROM, it cost the same amount of money whether it was 90% full or 99.99% full. There was of course a cost incentive not to go over 1mbit, or to get your size down enough to fit onto a 512kbit EEPROM.