I've worked in the AAA industry for years on many games. Just recently on Doom, I remember that code was so bloated you could open "hands.cpp" and just hold page down for days. I've also released many games on my blog, like close to 40 games on there.
So the main point is just try creating something different. Maybe for you it's not writing tiny code, maybe it's something else that seems pointless but you know you will have fun doing it and at least create something in the end. Trust me, it will be worth it.
Different constraints encourage or force different approaches, which gives you different results. You're not going to have a budgeting meeting over a <1K demo. You're not going to contract out to an artist. You're not going to use a large engine. You're not going to make a doom clone. You're not going to hum and haw over what middleware to use. It limits how much over-engineering you can invent. <1K is a pretty extreme constraint... but it's not that far off from what the demoscene does, and they discover some fascinating techniques and tricks in the process.
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.
That was his point.