Потому что cache-locality. Стек хорош в этом: функции работают преимущественно с локальными переменными, которые либо в регистрах либо на стеке. Всякие там адреса возврата туда же попадают, и всё получается неплохо. Если же мы начинаем раскидывать это по трём стекам, то в кеш начинает попадать больше ненужного -- из стека же в кеш переносится не нужная переменная, а кусок памяти в 64 байта (cache line), содержащий эту переменную. Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше.

Ну и потому, что накладные расходы на поддержание этих трёх стеков. Одно дело, когда всё сводится к одному указателю, под который мы условились в нашем ABI использовать один регистр, и даже не паримся хранить этот указатель где-то ещё в памяти, другое дело, когда у тебя три указателя, тут даже на x86-64, где регистров общего назначения не 8 а 16, будет не очень комфортно три регистра терять под стек. А уж на 32-х битной платформе, ты неизбежно упрёшься в необходимость хранить эти указатели в статических переменных, а эти статические переменные в кеше. И это добавит тебе лишний уровень индирекции: чтобы взять значение по его смещению от вершины стека, надо прочитать указатель стека из памяти в регистр, а потом разадресовать регистр.

При этом, я не удивлюсь, если x86 имеет в себе специальные фишки, которые делают операции со стеком быстрее, если стек построен на bp/ebp/rbp, а не на каком-нибудь там esi или r15. По-моему я даже читал об этом что-то когда-то.