It's pretty normal for game assets to follow their own version of Parkinson's Law https://en.wikipedia.org/wiki/Parkinson%27s_law and expand to fill the memory / performance budget available (usually at least +5-10%). That can be just a consequence of artists and designers trying to make the best game they can within the budget available to them and so isn't particularly a bad thing. That's why an experienced programmer building in a 'secret' extra buffer for use around ship became a thing.

Yeah, I've seen something similar done to the art budgets, but hiding memory from programmers is impossible if they had any clue, especially on PS2/Xbox (32M/64M RAM). You could read .map in 5 minutes and see anything suspicious. Same with delay loops - good luck with that. Though I've observed some "miraculous" recoveries due to utter idiocy. E.g. a PS2 game using double floats (because your time calculations will break after few hours with a 32-bit float, duh!). The CPU had 0 double support so they were all done in software and the library with it was rolled into the standard math lib. Or some incredibly misguided GPU programming done to a "non-lead SKU". Nobody notices that one system runs 5 times slower than another until it's close to shipping and you try to bring it to QA.

The point was not to hide memory from programmers who "had a clue" if they went looking. During production, most programmers on the team would be focused on delivering features they were responsible for and fixing bugs. If they were doing perf or memory profiling it would mostly be focused on whatever feature they were implementing. Only a few people on the team, perhaps only the lead, would be looking at global memory usage / perf on a regular basis and even then they'd mostly be looking for regressions. If anyone did happen across this they'd probably go talk to the lead (there might even be a comment directing them to do so) and be let in on the 'secret'.

At the end of production coming up to release is when there'd be a wider focus on general perf / memory usage to get everything to fit for the final release build. In my anecdote above, the reason I happened to find an example of reserved memory was just that I happened to be the first person to go looking in the right place with the right tools, not due to any particular skill or experience on my part (I was pretty junior at the time, this would probably have been around 2004 towards the end of the PS2 / Xbox console generation).

I don't buy it. If you need to shave some bytes the first thing you do is look at the map file or run a binary analysis tool to figure out what the best candidates for optimisation are.

And if your performance is poor the first thing you do is add some debug code to measure what is taking too long and where the biggest gains can be made.

The whole point of these tools is to make this stuff easy to find.