> От переполнения стэка ни один код не защищён. И ни один код
> не защищён от исчерпания памяти.

Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.

Есди я динамически аллоцирую память и ее ен было - то там по крайней мере вернут ошибку и я могу ее прочекать. И что-то сделать по этому поводу.

Но если это будет

void func1 (uint32_t n) {
  uint8_t arr[n]; // VLA!
  // do something with arr[] here
}

...и вызывать func1(10); func1(100); func1(100500); ...  то я вообще не знаю на каком n оно грохнется. И нет никаких способов это узнать, кроме как грохнувшись. Если *alloc еще фэйлить хотя-бы могут, то тут о фэйле узнаем только путем краха/системного факапа. Круто, да? Особенно в кернеле. Вы же будете очень рады что кернел в панику $%^нется без предупрежления, да?! Вместо фэйла внутренних операций, retry выделения памяти и прочих глупостей.

>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> При таком n, даже если всё в куче будет, на большинстве компов грохнется.

В случае динамической аллокации я как бы могу проверить успех операции. А тут сразу крах в репу, обработать нехватку памяти вообще совсем никак нельзя. И поскольку это рантайм параметр - получается код который очень ненадежный, скажем так, и может просто грубо навернуться если параметр неудачный. Без какой либо адекватной обработки этого вообще.

> И всё тут. И там и там надо ограничивать разрешённые значения N.

Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.