"to highlight the interesting possibility that "the simplest thing that could possibly work" might not actually (or always) be something that a complex later system can evolve out of."

One of my big focuses when I'm designing a system is not to get everything right up front, but to always be looking two or three steps ahead and making sure there is a reasonable path to get to where we need to be. It's one of the ways in which I definitely do not 100% subscribe to the idea of just doing what you need to do right now and consciously avoiding any other planning; if you're not poking your head up and keeping an eye on where the project is mostly likely to head, it's too easy to grind something into the very foundation of the architecture of a system that will make it essentially impossible to get to where you are actually going.

For example, if today, your system doesn't require any networking, then it may be advantageous to do everything as a fully local process with no networking involved, because networking is hard and expensive for your architecture. However, if you peer six months into the future and it's pretty obvious that you're going to have to add networking of some kind to your system, you can often cost-effectively hedge your bets without necessarily going to full-on networking usage by making sure that as you proceed in the initial steps, you tend away from any solutions that will make it impossible to add a networking layer in the future. Often you've got several options that are effectively the same price right now and have effectively the same benefits (never identical, but close enough), but have very different characteristics if you consider where the project is likely to go. You can often take out cheap insurance that pays off big later, and on those occasions where it may not pay off, it wasn't that expensive in the first place, so it's not that big a deal.

For a much more micro example, this is why every non-trivial file you write and every network protocol you specify should have a version number in it. It's virtually free today to put one in, even if you don't need it right now. (And for version 1, almost by definition you don't.) But the odds that you'll need it in the future, and that it'll be much harder to put in, are very good. Not putting a version number in today because you don't need it today is a great way to constrain your future moves.

(I actually still sort of endorse the radical YAGNI approach for young designers. Young designers who don't have a lot of experience tend to cargo cult the more complicated designs they see in other systems without deeply understanding what those are there for. I think there's a lot of advantage to taking a radically simplifying approach to your early designs, and you're likely to produce better work in almost every sense as a result if you do. But as you gain experience with that approach, bear in mind that it is something you will eventually outgrow. Armed with the direct experience of what problems arise and what solutions there are, and, alas, yes, the times you backed yourself into a corner, you'll grow the wisdom needed to peer ahead a bit and get the future course right often enough to make even better decisions. I'm not perfect at it, but I'm better at it than the hard-core XP propaganda seems to believe is possible.)