Стажировка в JetBrains и как мне почти удалось попасть на неё

и как мне кажется хорошо

Как говорили выше: если вы найдете ментора который давал задание и спросите напрямую, фидбек вы скорее всего получите.

Кроме структуры и расширяемости решения в целом(писали выше), ваш английский заментно хромает, а это тоже сказывается на качестве кода / быстром поике информации(вы скорее всего плохо "сканируете" условые issue на предмет того, что вас интересует). Это тоже могло повлиять на выбор стажера.

Я выполнил тестовое задание (и как мне кажется хорошо)

Давайте посмотрим.

При оценке работы будет оцениваться:
…
Качество исходного кода и наличие тестов;

Когда говорят о «наличии тестов», то чаще всего подразумевают unit tests.
В Java для это есть фреймворк JUnit, в Delphi — DUnit, в FreePascal — fpcunit.
У вас же просто батник, запускающий примеры из папки tests, это несколько не то.

Я бы не сказал, что оно сложное, скорее наоборот. Оно не требует каких-либо глубоких знаний теории построения трансляторов и крутого скилла.
Несмотря на то, что JB дают аж целых 7 дней, по времени у меня в сумме ушло около часа, а проект получился примерно в 500 строк кода.

Некоторое время на изучение теории выделить всё же стоит.
При парсинге у вас модифицируется входная строка, это явный признак того, что вы делаете что-то не так.
Стоит только добавить строковые литералы, как вызовы StringReplace() станут очень некстати. Сейчас же они просто лишние.

При этом вы не запоминаете позицию, на которой закончили в предыдущий вызов GetToken() и каждый раз начинаете обрабатывать строку с начала, хотя это совершенно избыточно.
Более того, GetToken() и FillSpaces() вообще не имело смысла писать. Обе функции имеют готовые реализации в FPC — ExtractWord() и StringOfChar() соответственно.

В Java и вовсе можно было взять StringTokenizer и получить лексер бесплатно.
К слову о правильности выбора языка.

type
 TGuuOp = class
   public

     OpType         : TGuuToken;
...
     OpReg          : Pointer;

В классах у вас все поля публичные, что не очень хорошая практика.
Тем более что декларация property это всего лишь одна дополнительня строка.

Поле OpReg используется для хранения ссылок на экземпляры классов TGuuOp и TGuuVar, но при этом почему-то имеет тип Pointer.
А так как TGuuOp и TGuuVar не имеют ничего общего, то возникает вопрос, почему ссылки на них хранятся в одном и том же поле.

OpType := TGuuToken(AnsiIndexStr(s, GuuToken));

Приводить целое число к перечислимому типу — плохая практика, по возможности стоит этого избегать.
Функция AnsiIndexStr() может вернуть в качестве значения -1, в этом случае в OpType вместо значения будет лежать мусор, не представимый типом TGuuToken. В case можно было использовать результат AnsiIndexStr() напрямую.

После того, как было написано объявление класса — я решил, что наиболее компактным и красивым решением было бы дописать парсер и небольшой синтаксический анализ в его конструкторе, что я дальше и сделал:

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

type
 TGuuVar = class
   public
     gvName: string;
     gvVal: variant;
     constructor Create(VarName: string);
 end;

Единственный поддерживаемый тип переменных — целое число, но вы зачем-то храните значение в поле типа Variant.

var
 GuuVars: TList;

Переменные вы храните в линейном списке, это потенциальные проблемы с производительностью на пустом месте. Хеш-таблица с именем переменной в качестве ключа здесь подошла бы больше.

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

Время жизни объектов у вас не защищено блоками try ... finally, на сколь-нибудь сложном коде это черевато утечками памяти.

Это то, что бросилось в глаза при беглом осмотре.

• В главной функции слишком много кода – здесь и парсинг аргументов командной строки, и чтение программы, и исполнение кода, и команды дебаггера. Как минимум просится разделение на отдельные методы, а то и классы.
• Требование „простота расширения функциональности“ не удалось выполнить. Все операторы и команды дебаггера обрабатывают огромные case. В последнем случае – прямо внутри main-функции.
• Большое количество мутаций в коде. Как уже написали комментаторы выше, самое проблемное место – парсер, сделанный через Delete, Trim, StringReplace.
• Требование „наличие тестов“ также не выполнено. В проекте нет тестов.

Deleted. Комментарий уже опубликовали мои коллеги.