Дивіться. Мова йде про реально складні ситуації. Якщо треба просто створити об'єкт певного класу - є звичайний конструктор, даємо йому параметри, маємо об'єкт. Все просто.
Якщо нам треба, залежно від параметрів, обирати підтип об'єкту (щоб функція повертала одного з нащадків) - це фабричний метод. Можна його робити і там, де точно буде відомий тип повертатися, це просто чистіший варіант.
А тепер розглянемо ситуацію... ну, скажімо, коли нам треба реалізувати настільну гру. Можливо, шахи, може, мафію, а можливо, MTG. В цілому ж всі такі ігри приблизно однаково граються, так? Є певний спільний простір (стіл), гравці, можливо, якісь частини з персональним доступом, ігрові об'єкти (фігури, карти, фішки), дошка (а може, це і є стіл?). І от ми хочемо, щоб виклик на кшталт
GameObject game = create_game(type, parameters);
створив нам початкову ситуацію у грі.
Але create_game має бути дуже гнучким. І гнучкість доведеться проявляти дуже глибоко і заплутано. Деякі методи будуть викликати цілу купу додаткових конструкторів (наприклад, конструктор шахової дошки буде створювати фігури, причому різні, залежно від того, це шахи чи шашки). В результаті має сенс створити фабрику
BoardGameFactory
з методами на кшталт
create_players
create_board
create_figures
setup_game
і т.д., а потім створити у неї нащадків з різними реалізаціями цих методів. А create_game буде залежно від параметрів смикати різні методи фабрики в різних послідовностях (наприклад, для ігор без дошки не буде викликатися create_board). Коротше - це не від хорошого життя такі абстракції придумали 
