From the reference you cited:
Make sure that the filter for your roll-up summary does not encounter a formula field that results in “#Error!”. If your filter criteria uses a formula field that results in an error, no matches are returned for that filter criterion. For example, if your roll-up summary filter is “Formula Field equals 10” and two records contain errors while one contains the value “10” in that field, your summary only includes the record with the value “10.”
Your formula will produce an error any time IF(ISPICKVAL(StageName, "Closed Won") or IF( ISPICKVAL(StageName, "Closed Lost") evaluates to false. That's why SF won't allow you to use your formula field.
First, thank you, Ralph, for asking this question and putting yourself out there. As a matter of communication I don't mean to call you out on anything at all, but I want to give a detailed, (hopefully) thoughtful answer to a detailed, thoughtful question.
Are there any best practices out there for testing apex code that is driven by formula fields so that changes to the formula field formula don't break your test?
As someone who'd asked the same question myself, I think I understand why you posted to Stack Exchange. However, I believe a better question is, "How can I make sure critical formula fields are tested properly to protect against unintended consequences?"
I believe you should want changes to formula fields to break Apex tests, especially when your app logic depends on those formula fields. Imagine having an Apex class to create the output that the formula field currently produces. In that case you're forced to write an Apex test for that other class, and in the app logic that you are writing you would rely on proper test coverage of the other class.
A formula field is simply another means of automating business logic. And just like other means, such as Apex, Visual Workflow, JavaScript, workflow rules or Process Builder, a formula field used as a critical automation component should have adequate test coverage.
So, regarding this idea:
Good test methods shouldn't break when administrators make changes.
I believe that good test methods should break when administrators (or developers) make changes that impact the app logic that you've implemented. I think this is the only way to sustainably work in a team environment with multiple admins and devs.
Recommendations
All that to say I support both recommendations from NSjonas and Bobby White.
... treat the Formula Field as though it were a stand alone class and ensure that you have adequate code coverage for all of the branches that are implicit in it.
-- Bobby White
I would recommend de-coupling the class with the actual instance of the object if possible. That way you can test the branch conditions individually by passing whatever value you want into the code.
-- NSjonas
Best Answer
Instead of a formula, create a new Date or Datetime field, and update it to NOW() via a Workflow Field Update or via a trigger, whenever you detect that the Checkbox value has been changed from False to True.