> Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?

Stack guard страница фактически не требует никаких накладных расходов, она один раз ядром помечается как недоступная для приложения, а потом процессор генерит исключение когда к ней происходит обращение. Процессор постоянно проверяет эти права, не только для охранной страницы, а для всех.

А вот указатель стека проверять -- это реально накладные расходы, потому что стек реально реализован через регистр rbp, который указывает на вершину стека, и приложение с ним может играть как угодно. Выделить память под новый стек из кучи и нацелить rbp туда, например. Есть даже готовые функции в libc для подобной игры с rbp: о них можно почитать в info libc 'Non-Local exits'.

Большая часть софта не делает этого, оставляя всю работу со стеком компилятору. Но даже там проверки указателя стека могут оказаться накладным удовольствием. Указатель стека меняется при каждом вызове функции, при каждой инструкции push/pop, при каждом объявлении локальной переменной в C... И при этом компилятор, в общем-то, не знает границ стека, об этом наверное только компоновщик узнаёт, тот которые объектные файлы в готовый бинарь собирает. А может быть даже и он не знает, а уже динамический компоновщик устанавливает эти границы, когда грузит бинарь в память процесса. Но с этими тонкостями я не разбирался.