[Dmitry A. Soshnikov]

И пришел в результате к синглтону

Ну, несомненно, в плане многих проверок - да. Но терминологию "Синглтон" и этот паттерн (при той же организации) можно и не использовать. Например, в плане Java-Swing-a или JavaScript-ового Ext-фреймворка (который вдохновлён Swing-ом) можно повсеместно видеть код:

getPanel: function () {
  if (!this.panel) {
    // вычисления и создание панели
  }
  return this.panel;
}

// и потом в 10 методах
// this.getPanel()

Я говорил об _этом_, когда упомянул разновидность memoization. Здесь ближе по _идеологии_ именно к этой сущности, но не к Singleton. Хотя, в определении "возвращает один и тот же объект" - да, можно и терминологию "Singleton" приплести. Если же это ещё подкрепить и оператором new, то вообще ещё больше похоже (но сути не меняет).

На кой ляд? Если можно просто создать объект?

А это в плане, когда нужен просто объект и известно, что он, действительно, будет нужен.

В этом случае, смысла в дополнительном конструкторе нет. Более того, в том же Ext-e, например, люди пишут, опять же, в Java-Swing-стиле: именно для организации наследования создают наследника от какого-то базового "класса", даже, если затем этот наследник породит всего _один_ объект. Спрашивается, зачем конструктор? Для наследования. Из-за этого приходится его плодить. Если бы можно было по стандарту (а не только через __proto__ в конкретных реализациях) менять свободно прототип, то пункт с наследованием бы отпал, конструктор был бы не нужен (как, кстати, и new).