Какое собственно Windows дело кратен или не кратен указатель стека 8 в программе, раз обработчик все равно уже найден и стек дальше исследовать не надо?

Думаю дело такое, что компилятор рассчитывает на определенное выравнивание стека при вызове функций. И рассчитывает он на это не просто так, а для того чтобы можно было использовать инструкции SSE при работе со стековыми переменными. Впрочем конечно можно было бы насильно подравнять стек, запомнив в нем же оригинальное "неровное" значение.

Диспетчер берет следующие 8 байт «вглубь» стека, надеясь, что это очередной адрес возврата, и пытается по ним все же определить, какая из известных, т.е. зарегистрированных подпрограмм выполнялась. Но это очень шаткая и сомнительная технология.

Технология конечно ужас-ужас в имплементации, зато имеет нулевой оверхед в рантайме. Самый интересный момент в статье не рассмотрен: а именно то что может быть в RtlAddFunctionTable(..RUNTIME_FUNCTION..) — UNWIND_INFO, которая является в том числе подсказчиком для того дизассемблера-симулятора. Прологи/эпилоги функций соотстветственно должны быть не абы-какими, а соответствовать возможностям симулятора, это как бы часть соглашения. Вобщем х64 стал еще немного дальше от любителей завернуть чтонить на асме.

Во-первых, исключения бывают в результате разных ошибок. При некоторых ошибках далеко не факт, что стек вообще содержит что-то разумное.

Технология придумана для "санкционированных" исключений, то есть брошенных руками. Работоспособность программы после какого нить illegal instruction или поломанной памяти на самом деле никому не интересна.