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

Ну в Брусе не совсем классический фрейм, он только для локальных переменных, но не для аргументов функций (для них отдельный аппаратный стек есть). Если я правильно путаю, именно в таком виде сейчас реализовано в Питоне под Брус. В моей реализации Си для Бруса аргументы тоже через стек, локальные в массиве (так исторически сложилось), а фрейм не используется.
Очевидно, что при проектировании системы команд учитывалось, что под Брус будет компилятор ЯВУ, поэтому заранее подстелили соломку в виде фреймов на случай, если вдруг будут локальные переменные (а почему бы им и не быть?). Ну и раз уж выбраны достаточно широкие команды (16 бит), то нужно максимально заполнять их, чтобы не гонять туда-сюда полупустые инструкции.
Интересно все-таки, какой ширины машинное слово дает максимальную плотность кода?

О, это замечательная тема! Тут ведь вопрос в том, сколько переменных одновременно "живы" (т.е. от начала упоминания в правой части выражений и до последнего присваивания). Если таких много, их хотелось бы один раз прочитать в регистры и потом ими пользоваться. А если это 123 A ! 345 B !, то тут много регистров и не надо, вполне хватит стека и 0-операндной системы команд. Поэтому можно сразу обратиться к компиляторам, абстрагированным от регистровой модели, и попробовать с их помощью сгенерировать код под разные варианты.

Формально 0-операндный процессор при хороших условиях однозначно выигрывает. Вопрос только в том, не поставят ли его в нехорошие условия, заставив держать на стеке много переменных и постоянно жонглировать ими. Но есть предварительное ощущение, что "существует класс алгоритмов, для которого 0-операндный процессор покажет наилучшую плотность кода".

Ах, да, я ж как раз и подразумевал стековые процессоры, просто не указал это явно. И хотел сравнить их по плотности между собой, а не с регистровыми.
Пока делал только 3/4/6-битные Форт-процессоры. 4/6-битные почти для всех скомпилированных примеров дают заметно более плотный код в сравнении с условными x86/6502/AVR/etc. Вполне допускаю, что есть примеры, на которых эти стековые процессоры уступят, но пока не встречались такие. 3-битные, естественно, послабее, да и сделаны, если честно, для галочки, но даже они часто опережают регистровые процессоры по плотности. Стековые между собой соотносятся примерно так (и для сравнения в таблицах пара регистровых):

dhrystone:
Интерпретатор basic:
Если грубо, то 3-битные уступают 4-битным раза в 2, а 4-битные - процентов на 10-20% 6-битным. Понятно, что в зависимости от теста разница может уползать в ту или иную сторону. Но точно все 3-битные сильно уступают 4-битным, а все 4-битные уступают единственному пока 6-битному. Но это именно на моих процессорах/компиляторах. А у кого-то другого могут получиться совершенно другие результаты.
Вообще, интересно было бы сделать 5-битные команды, а также 8/9- и 16/18-битные. А еще могут быть комбинированные варианты, в которых либо длинный литерал, либо несколько упакованных команд небольшой длины.
Почему-то не покидает ощущение, что 8/9-битные дадут более плотный код в сравнении с 16/18-битными, а вот что будет в сравнении с 4/5/6-битными, пока сказать сложно.

В идеале тут нужен компилятор, который сразу заточен на стековость процессора.

Что-то Брусом навеяло такой челлендж: по одному блоку BRAM на видеопамять, RAM, ROM и шрифты/спрайты. Такой вот экстремальный минимализм. И что можно выжать из этого безобразия? В теории оно потом влезет в Tang Nano 1K, где как раз 4 блока на борту, а может даже в 5510, хотя в последней нет BRAM.