You can then use them to write succinct, clean code and figure out what your program actually needs to do as you go along. This is useful because even the most detailed plan inevitably misses both details and opportunities.
How could this kind of approach be used in game development? This is similar to building an engine and then building a game on it. Still, an engine is usually considered to be a monolithic thing, whereas bottom-up game programming would be more about loosely integrated, combinable abstractions. In the absence of Lisp, you could create a DSL, or a fluent interface, or abstractions supporting a scripting language.
Instead of coming up with the idea for a game and then writing it, you decide what kind of game you want to write, and then build tools to make games of that type. You build prototypes with these tools and refine them as better abstractions become available. Ultimately, you settle down on a particular game concept, complete it, polish it, and release it.
For example, if you want to build an action-roguelike, your abstractions could include things like units, the presence of skills, timeouts and resources. For a tile-matching game, abstractions could be about matching rules, placement rules, transformations, etc.
Undoubtedly creating these abstractions takes longer than just writing a prototype. But on the other hand, it's really hard to see in advance what will make a game fun. This is usually solved by writing a prototype and hacking around until it works. At that point, you either have to throw away the prototype and spend a long boring time re-coding a game you already have, or spend a lot of painful hours cleaning up the prototype to turn it into a real game.
Bottom-up game programming promises the flexibility of prototyping without its wastefulness. This is all theoretical, so at some point I will try a small game project in a bottom-up style to see how well it works.