You said: "On the other hand, I can only easily stub Time.now() *everywhere*, so I need to do this carefully. This means that we can have the singleton testing problem (I have to remember to reset the singleton to its original state at the end of my test) everywhere, all the time. Great power, great responsibility, all that."
Have you done this in Ruby? I’d agree with you if I was suggesting to manually overwrite code, but note that in my example code I said *not* to and gave two other options: Timecop and Mocha. Both gems take care of your “singleton testing problem” by restricting the overwrites within the scope of a single test.
This means that you don’t actually have to be very responsible. If you overwrite the behavior of Time or any other object, it will be reverted in the next test.
You wrote: "I don't want to get the current time, because the current time binds me to a specific context. This makes the code less easily reused. So far, this doesn't sound like much of a problem, because I'm never going to reuse "find all customers with recent, open orders", right?... If I keep now() buried deep in my code, then I probably don't see this. I know that, because I've kept now() buried deep in my code and not seen this. I've also seen dozens of code bases in which they're kept now() buried deep in their code and not seen this."
You don’t have to get the “right” answer first. If a developer finds him or herself bound to the wrong context, the solution is easy: Change the code. If the programmer was following good programming practices (like SRP and TDD), the code will be easy to refactor.
Time is a specific problem, as it's a static call that's in multiple levels in the code. This problem would have to be fixed by following a good design process like TDD. As soon as the dev writes the first test, the dev will be forced to move into some controllable abstraction. Tests are where the dev can "see it."
I've found that looking ahead for reuse is as practical as reading tarot cards. Nobody knows what the future holds, not even the code whisperer. There are a few times when it's obvious (your example of recent versus close-to-a-date does NOT apply), but in most cases it's better to refactor a working, tested solution than trying to guess ahead.