It's costless to replace == with >=...

I disagree. It's extra code to read, to understand, to be executed, and to maintain. It's very little in this case, but I think it's an awful reason to do something because "it might be needed in the future."

The best way to make your code extensible is not to add in features you think you might want someday. The best way is to write simple, readable, testable, and simple (yes, doubly simple) code that does what it needs to do and no more. If you fall into the trap of thinking that you need to plan for things you can't foresee, you'll be hampered in your ability to make changes. "I can't change this code because it plans for a case I might need down the road, and I've already written it."

I don't think of that as "defensive programming" but rather fearful, packrat programming. In my mind, defensive programming is checking error codes and boundary conditions. (You could also argue that, given my preference above, it's not adding things that don't have an immediate benefit, but that's a bit of a stretch.)