Founder code is great for illustrating an important architectural choice (e.g., how to make a system scalable). Founder code is crucial for developer tools where the product is a system for building software (it's worthless to design developer tools without using them yourself). Founder code is especially helpful in UX design. Complex animations, transitions, and interactions can be hard to describe. Data visualizations take a long time to play with before you discover the right combination that's compelling.
The concept of "founder code" also explains a lot of the bad things I've seen in codebases over the years. You can imagine this is the mindset of a programmer solving a problem the first time around: "Better to have something working the slow way than not at all. Maybe someday we can make that awful bookkeeping function fast by using a better architecture. For now, this is going to get us by and provide the functionality we think our users need."
Looking back, this may justify my style in general. My teammates have described my code as having a particular flavor. When most programmers encounter a barrier in their path, they'll often find a way around it by writing a bit more code, a better abstraction, etc. They do something that solves the problem, but still preserves energy for the road ahead. When I encounter a barrier, I often find a way to bust through the center of it, even if it means causing long-term damage to the codebase or my forward momentum. My goal is not a sustainable, long-term implementation. The purpose of the code is to convey behavior.
Founder code is fundamentally just another name for prototyping. When a team has grown to the point where other (better) programmers have time to rewrite the original founder code, that's success. The job of founders is to hire the right people to rebuild the current or next version of the system correctly. Thus, the ultimate goal of founder code is to become obsolete. Andy pointed out that founders are totally comfortable with this idea, where many other developers may be enraged by the sight of their code being ripped out and replaced (it's perceived as spiteful).
For my current project, most of my original work has been replaced (some of it I even rewrote myself in a better way — I'm not always bad!). But even though my code is gone, the behaviors I outlined in the first prototypes carry on. Many of the fundamental assumptions and design choices I made still exist, for better or worse. This means I can still help my teammates reason about the codebase, even though it's changed so much since I wrote the first line over four years ago.