It's not about changing the interface frequently. It's about changing it poorly.

But as churn gets more expensive (and this is sometimes inevitable), you want to try harder to avoid it. A process is only agile while revisions are cheap.

It seems like a lot of arguments could be avoided if it were more widely understood that this is a trade-off, with agility on one end and stability on the other, and stability is often good. Particularly when a lot of people depend on you.

"Unless you're scared of a little moving fast and breaking things."

It's a common pattern. When a software system becomes complicated and fragile, it's quite common for the developers to get scared of breakage and move slowly.

Sometimes there are fundamental reasons for moving cautiously, and sometimes they're accidental reasons that could be fixed with a better process (such as better tests). Either way, just being more reckless isn't going to help.

So if you had in mind a generic upload UI where it would look weird with only one choice in the menu, then better to skip the menu entirely for now. It makes the UI worse, and implementing the menu is more work. Plus you don't want to end up with dead code lying around if plans change, since that could confuse someone later.

But if none of those considerations apply and the generic version is actually easier to implement and the UI is just as good, sure it's fine.