使用者がクラスのインスタンスを生成出来るようにするために、publicコンストラクタの代わりにstaticなインスタンス生成メソッドを提供することを検討するべき、という内容です。

記載内容

メリット

以下の5つのメリットが挙げられています

名前を付けられる
呼び出しごとに新たなインスタンスを生成する必要が無い
戻り値型の任意のサブタイプのインスタンスを返すことが出来る
引数に応じて、返すインスタンスの型を変えらえる
返されるオブジェクトのクラスは、ファクトリメソッドが書かれた時点で実装されている必要が無い

デメリット

以下の2つのデメリットが挙げられています

サブクラスが作れない
プログラマがインスタンスの生成方法を見つけるのが難しい

考察

メリットについて

ファクトリメソッドは特に不変クラスと相性が良いと思います。
特に「呼び出しごとに新たなインスタンスを生成する必要が無い」は、
実装当初は毎回インスタンスを生成していても、将来、インスタンスのキャッシュ等を追加できます。
(コンストラクタをpublicで公開してしまったら、利用側のコードを修正しないとなりません)

返すインスタンス型に関する3つのメリットは、インタフェースにstaticファクトリメソッドを定義すると、より良いかもしれません。
定義としてはインタフェース自身を返すように記載しておき、実際に返すのは、パッケージプライベートの実装クラスにしておけば、
利用側に実装クラスを隠すことが出来、将来の拡張が容易になります。

デメリットについて

デメリットの1つ目「サブクラスが作れない」は問題ないと思われます。
機能追加時に、継承よりもコンポジションを選択すれば良いためです。
(むしろメリットだと思えるくらいです)

「プログラマがインスタンスの生成方法を見つけるのが難しい」は少し問題です。
IDEの助けがあっても、
ファクトリメソッドの名前が分かりづらかったり、JavaDocの記載が不十分だったりすると、
適切な生成方法を見つけるのが難しくなりそうです。
9ページの命名規約は確認しておいたほうが良いです。

まとめ

特に、不変クラスを作成しているのであれば、ファクトリメソッドの提供(および、コンストラクタを非publicにすること)を検討したほうが良いと思います。
提供する場合は、命名規約に注意するべきです。