[emptybits]

That's an excellent description of why I recall the days of inherent constraint as fondly as I do. I was an 8-bit console programmer back in the day. I've also worked in a later era of sophisticated engines, huge teams, artists and coders often assigned narrow specialties, managed by tiers of development directors and producers and administrative staff. Pros and cons, for sure.

So in hindsight, two more joyous aspects of constraint in game development (whether inherent or self-imposed):

1. Bugs, testing, quality. When you know your binary will be burned into a cartridge with no hope of a patch or update, one tends to code and test carefully! You fill your allocated ROM banks with as much "fun" as you can (code and content) but you know it must be well tested for both play balance and bugs because you can't release a version 1.1. :-)

2. Scope creep. This is much easier to avoid when you're given (e.g.) four 16KB banks of ROM for all your code and assets. So you burn midnight oil for mere months, not years, before you find out if your game is a hit or a stinker. Short feedback loops. More variety per year. Refreshing.