Инициализация в С++ действительно безумна. Лучше начинать с Си

Вот именно поэтому алгол и его потомки и сошли со сцены. Почему в 80е все писали на Паскале (кто-то на СМ'ках, кто-то на PC, да даже и Mac — тоже изначально был на диалекте Паскаля написан), а уже в 90е — перестали? Во-многом — именно потому, что Модула-2/Оберон и так далее не позволяли использовать сущесвующий код, а C++ — позволял.

Увы, но иначе — никак. Либо у вас 100500 культурных слоёв, либо вы — странчика в википедии.

Почему в 80е все писали на Паскале (кто-то на СМ'ках, кто-то на PC, да даже и Mac — тоже изначально был на диалекте Паскаля написан), а уже в 90е — перестали? Во-многом — именно потому, что Модула-2/Оберон и так далее не позволяли использовать сущесвующий код, а C++ — позволял.

Устроят тот же бардак

Ну дык, об этом я и говорю. Любой тип Т — инициализированный, инвариант сохраняется, MaybeUninit<T> — нет, и такты не тратятся.

и других менее прямолинейных языках.

Назовите "другие менее прямолинейные языки" с таким зоопарком UB как в C или C++. Я вот затрудняюсь.

Лучше набить шишек на C

Это всё хорошо если задача "выучить C". А если задача "научиться алгоритмам" или там ещё что, то "набивание шишек" происходит в ущерб основной задаче.

А вообще UB это в целом скорее плохо, хотя бы потому что, как я выше сказал, проскакивает даже у очень опытных программистов на C и/или C++, чего уж говорить о юниорах. Статический анализ помогает, но это не "серебряная пуля". В результате какие-то невероятные человеко-часы тратятся на отладку, или ещё хуже, оно потом не пойми с чего валится "в бою". На мой вкус, совсем не хорошо.

Много программистов на плюсах в SFINAE и в мета-программирование на шаблонах не влазят.

Пусть себе не влазят. Чтобы эффективно использовать template-ы даже без SFINAE и хардкорного мета-программирования, надо знать правила вывода шаблонных аргументов. Иначе иной раз возможны сильно неприятные сюрпризы. Правила и так-то не всегда очевидны, а если учитывать ещё и C++11 с "универсальными ссылками" (которые на самом деле фикция) и C++17 с выводом шаблонных аргументов классов, неожиданно оказывается, что за 10 минут даже просто рассказать внятно про это всё не получается.

int a[10] массив хорошо пока размер известен в compile-time

Начиная с C99, то есть уже без малого 20 лет, C умеет переменную длину массивов на стеке, определяемую в run-time. Вы, наверное, с C++ опять попутали? C++ действительно по стандарту не умеет до сих пор (хотя подвижки есть, плюс компиляторы поддерживают в виде расширения)

По поводу остальных проблем

Там "остальных проблем" ещё вагон и маленькая тележка. Ну не получается учить плюсам "мимоходом". Или в результате имеем юниоров, которые на бумаге "умеют плюсы", а на практике в коде какой-то кромешный ад. Из реально попадавшегося, многомерные массивы в виде T*** или не лучше vector<vector<vector<T> > >, массивы из пяти элементов в куче вместо стека, использование в паре new[] и delete, вообще использование new и delete где без них можно обойтись, использование std::vector для трёхмерных векторов… ну и естественно регулярно "у меня не компилится", или хуже того "у меня компилится, но не работает"… Извините, наболело.

Я не наступал.

Может вы просто шаблоны не писали. А то ведь:

template<class T> void demo() {
  T t; // Как здесь получить дефолтную инициализацию?
  ...
}

Что, если T — это int?

Оно и раньше позволяло так делать.

Такое ощущение, что вы в другое время жили. Ибо, вот что говорит gcc-4.7 (древнее у меня нет) с ключиком -std=c++98:

t1.cpp: In function 'int main()':
t1.cpp:4:7: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default]

А вот что говорит не менее древний VC++ с версией 17.00 (это вроде 2012-я студия):

t1.cpp(4) : error C2601: 's' : local function definitions are illegal
        t1.cpp(3): this line contains a '{' which has not yet been matched
t1.cpp(4) : error C2143: syntax error : missing ';' before '}'

Как по мне, так косяк довольно серьёзный

А кто-то спорит? Да, косяк оказался серьезным. Но не ошибается лишь тот, кто ничего не делает.

Ведь есть же абсолютно логичное решение

Задним умом все сильны.

Тем не менее, я могу себе представить что у комитета и у компиляторостроителей были вполне себе веские причины обязать использовать constexpr.

Вы ошибку компиляции-то видели?

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

Директива constexpr имеет тот же смысл, что и override.

Проблема же в том, что тогда проверка на constexpr будет осуществляется не при определении функции, а при её использовании.

#include <iostream>

constexpr int this_is_stupid(bool stupid_arg = true) {
    if (stupid_arg) {
      std::cout << "WTH is this?" << std::endl;
    }
  return 42;
}

int main() {
    this_is_stupid();
}

char buf[this_is_stupid(false)];

char buf[this_is_stupid(true)];

template<class T> struct dependent_false : std::false_type {};
template <typename T>
void f() {
     if constexpr (std::is_arithmetic_v<T>)
         // ...
     else
       static_assert(dependent_false<T>::value,
                     "Must be arithmetic");
}