Every engineer I've worked with has, at some point, sat in front of a design and silently decided to make it just a little more interesting than what was scoped. We dress it up as "future-proofing." Sometimes it is. Mostly it's the part of us that wants the work to be ours.
Here is the boring case for shipping the boring version first.
The compound math
A boring v1 lets the team learn whether the feature matters before you've invested in the ambitious version. Five out of ten boring v1s get killed in the next sprint, because nobody used them. You just bought back two weeks per killed feature.
The remaining five graduate to v2 — but now they graduate with usage data, and v2 is informed by what real users do, not what you imagined they'd do. That feedback loop is worth more than any architectural cleverness you could've added in v1.
The ego cost
This is the part nobody writes about. Shipping the boring version means resisting the part of you that wants the code to be admired. The good news is that shipping itself becomes admirable, over enough cycles. Engineers known for shipping accumulate more interesting problems than engineers known for craft. Eventually you get to do both.
Ship the boring version. Then ship the next thing. The interesting code is downstream of the cycles.