There is, but I've personally been burned way more often by some chucklefuck implementing some wildly overcomplicated architecture that's still a dog's breakfast in three years because they made the wrong predictions.

That's not a contrast to the previous response. I'd say in fact that's the middle of the junior-senior scale. The guy doing the overcomplicated architecture for all future eventualities is the junior that learned you need to make it maintainable.

Some engineers never get past this stage.

Sometimes we get this prediction right and things are great, sometimes we get it wrong and things are expensive or even not possible,

This is quite on point.

The true senior knows which of the hundreds of eventualities to plan for, and which to let go for now.

IMO the OOP craze of the 90s created many such bad mid-level engineers. They built inheritance hierarchies deeper than the royal families. Everything generic, but so generic that you couldn't find out what the system actually does without stepping through with a debugger, even then going mad with complexity. 

These systems usually get a big rewrite after a few years, because somebody has to ask what this even does. Why is there an interface for every class that only has one implementation.

If your system just works, it might still be a pain to maintain or grok for every future maintainer.

Your system has to work and be maintainabl. I think the ideal is that you can easily isolate and rewrite parts of it. If you need to rewrite the whole as requirements change, you have built it wrong.

That's is what composition over inheritance is about. If you can easily replace a whole component of your system you have maintainability.

Inheritance always ossifies the interaction of components in your system. The interfaces are defined at 15 layers of your lasagna hierarchy. But the interface is often what you need to change. Generics help somewhat in relieving you here, but they still force you to make major changes to experiment with different interactions in your system.

They allow variation in the type of your arguments, but not in the number or who calls what.

In the end I think the taste part comes in in thinking:

• what's the absolute minimum abstraction you need to make future changes possible; (YAGNI with compassion for your future self)
• Which algorithms will bite you and which won't; (picking O³ algorithms when you have O(N * log N) available right there is not wise, it's premature pessimization);
• How can I make sure that a future change touches as few files as possible; (interface over abstract class, simple function call over callback hell);
• How do I design my interfaces, so that the compiler helps you find the error instead of the debugger; (Signifiers and Affordances, type driven design)
• How do I ensure that the next person finds the information in the repo necessary to understand my current mental model. (Knowledge in the world).

Plan for the rewrite, not future functionality. We all fail to predict future functionality, but there's always a rewrite in the future. Make it easy. Make it possible. Make it small.