For me I like the approach Kent Beck puts forward in XP (not sure if it's "his" idea or someone else's but that's where I first heard it):
It's hard enough to solve today's problems without trying to work out what tomorrow's problems are and solve them too.
Developers can spend a lot of time on solutions for requirements that don't exist, edge cases which will never occur or even genuine problems where the impact of the problem is significantly less than the cost of preventing it.
This is time that could be put into things users will really want and use, things which will give them benefits that will massively outweigh even the inconvenience that will be caused in the unlikely event that one of these things actually happens.
Beyond even this non-optimal outcome for the user, the impact on the developer of over engineering in this way tends to be over complex code that is harder to support and harder to enhance.
So for me if you know, or can be fairly certain, that something is a requirement or is going to cause a problem then address it, if not then don't.
You may have to come back and rework it when it turns out that there was a wider requirement than you originally implemented, but generally the total effort you put in across the project will still be lower because in most cases that won't happen.