Because you should use mock objects as far as you can apply TDD, whereas you can design and *discover* interfaces (and roles), and assign responsibility. On the other hand, in front of a third-party library you cannot follow this process, since the code is not under your control, and you cannot modify it.
To verify the correct integration with libraries or external components, which are out of you domain, as well as with integration tests, you may use fakes or stubs (and, by the way, the example in the Uncle Bob’s post is actually a stub, not a “hand-rolled mock”).
- http://www.jmock.org/oopsla2004.pdf (I’m quoting again this paper, because it’s a *really* good starting point to understand this approch to mock objects)
- http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html (if you like to deepen the “Don’t mock third-party libraries” and “Don’t mock value objects” topics)
- http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf (yet another paper, very good)
- and if you want to know more about the history of mock objects: http://www.mockobjects.com/2009/09/brief-history-of-mock-objects.html
I hope I give you some useful feedback on this topic!