It helps with testing because you can write the session facade in such a way that it will accept a scope as an argument (ie setSessionScope()). I just default this to the real session scope so that is what the real application will use. But it means if I write a unit test, I can pass in a structure to the facade and it will use that in place of the session scope. That way I can run tests against the CFC without having to set up some sort of dummy <cfapplication> with the session scope turned on just to let the test run. The same goes for any other components where you were going to use the session scope prior to adding a session facade. They don't need to know anything about the session scope either, all they care about is that they have a session facade object they can use. So during testing, it's easy to supply the CFC with a mock session facade that just mimics what the real session facade CFC would do, without using the session scope.

As is virtually always the case, encapsulating something makes it easier to test. Likewise, how easy it is to test something is a good indicator of the quality of the design. If you have to create an application scope, session scope, or lots of other components just to test one thing, it means you probably need to refactor to reduce the dependencies. Components should know as little about the rest of the system or the context of their use as possible.

I don't have any articles on session facades specifically, but the underlying idea (encapsulation) is the same for any object. Any book or article on good OO design would apply.

Hope that helps.