Билдеры или конструкторы? Рассуждаем вслух

Хорошо обстоят:

val info = Info().apply {
  email = "my@example.com"
  phone = "+1 999 000 00 00"
}

val info = Info(
    email = "email@email.com",
    phone = "79998888888"
)

Отличия:

1. val, вместо var. Если переменная неизменяемая, то val (как в нашем случае)
2. new писать не надо. В Java классы начинаются с большой буквы, а методы — с маленькой. По этому признаку легко отличить вызов метода от вызова конструктора.
3. ; не требуется, если это последний statement в строке.

В примере выше создается immutable объект из декларации class(val email: String, val phone: String).

Однако, если её немного изменить на data class(val email: String, val phone: String), то можно применять паттерн "прототипирование":

val default = Info( ... )

fun customEmail(email: String): Info {
     return default.copy(email = email)
}

Если не изменяет память и в java давно почти также

var info1 = new Info() {{
    email = "email@email.com";
    phone = "79998888888";
}};

Как с этим дела обстоят в котлине, кто в курсе?

Замечательно:

val info1 = Info(email = "mail@example.com")
val info2 = Info(email = "anothermail@example.com", phone = "1 234 567 8900")
val info3 = Info(uuid = UUID.randomUUID().toString())

Не совсем корректный пример. Т.к. тут либо использовать C#9 с init свойствами, либо объект получится мутабельный, хотя в примерах, если не ошибаюсь, делали иммутабельный объект

Или же с давно существующим в C# синтаксисом через имена параметров:

var info1 = new Info(
    email: "email@email.com",
    phone: "79998888888");

С моей субъективной точки зрения для объектов, которые являются просто описателями некой небольшой сущности, билдер выглядит не особо нужным. Другое дело, если мы создаём сложный объект, где можно добавлять множество различных параметров. Кстати, тут неплохо бы сказать и о fluent API, обычно являющимся неотемлемой частью реализации билдера.

Ну и, разумеется, зависит от языка. Если где-то нельзя поименовать передаваемые значения, то билдер может оказаться полезным воркэраундом.

Не по теме поста.
Сам рекомендовал бы — Java. Полное руководство | Шилдт Герберт, лично учился на ней.
И книги банды четырех.

поэтапная инициализация

Абсолютно согласен.

И тогда никакой статической типизации, имхо, очень плохое решение

Этот класс ненужен для приложения, он не принимает участие в бизнес логике, единственная его функция — вызвать конструктор объекта.

Класс добавляет читабельности, т.к. вместо конструктора вида

var complexObject = new ComplexObject(
    0,
    id,
    name,
    null,
    null,
    uniqueName,
    firstAttribute,
    null,
    someCondition,
    isAvailable)

получается код вида

var builder = builder
    .StartsFrom(0)
    .WithId(id)
    .WithName(name)
    .WithUniqueName(uniqueName)
    .WithFirstAttribute(firstAttribute);

if (isSomeCondition) {
    builder.IsSomeCondition();
}

if (isAvailable) {
    builder.IsAvailable();
}

var complexObject = builder.Build();

В данном случае, можно передавать только нужные параметры и не передавать null, которые к тому же портят читаемость. Что скрывается за первым null? Ну го смотреть объявления конструктора, чтоб понять.
Так же, можно добавлять сложную логику, типа вдогонку

if (isAdmin) {
    builder.SetPermission(Permission.Write);
    builder.AllowEditing();
    builder.ShowHiddenValues();
}

нет никакой проблемы в том что в классе будет 5, 10 конструкторов

Есть проблема, что при добавлении нового параметра придётся всех их обновлять и могут возникнуть коллизии, типа есть конструктор без параметров, а есть с числовым параметром. Добавляем новый обязательный числовой параметр — первый конструктор превращается в старую версию второго и это легко упустить при рефакторинге.
Если конструкторов много, то при создании объекта нужно всех их изучить, ибо вероятно будет много похожих сигнатур с параметрами-примитивами, ибо «Одним классом меньше в проекте — проще для понимания.» и вряд ли для параметров будут созданы какие то специальные классы.
Дополнительно, билдер удобно использовать когда создаётся действительно сложный объект. У меня есть пример, где строится сложная таблица с большим количеством параметров и только билдер имеет порядка 20 методов установки свойств.