Вопрос - оптимальная степень оптимизации. Заметил косячок на максимальной оптимизации. Какую лучше ставить, чтобы не проверять каждый раз правильно ли откомпилированно?

Есть такая традиция - отключать оптимизацию при отладке [DEBUG mode]: багов по определению нет т.к. идет тупая сборка (компиляция) из готовых и неоптимизированных кусков.
После того, как разработчик отработал алгоритм в функционально законченном виде - приступаем к оптимизации [RELISE mode]. Мой практикум в программировании под ИАРом показывает, что косяки выявляются в таких кусках кода, которые не красиво написаны в сЁвом синтаксисе. Например, в какой-то ранней версии (не помню) функция не возвращала сложную составную переменную, получаемую в строке с return-ом, в более поздней - работает !!!
Пусть специалисты меня поправят...

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

Всегда использую только максимальную оптимизацию (в том числе и в дебаге - на последних стадиях отладки). Единственный "глюк" возникал только с участками кода где в условии цикла используется значение переменной не изменяемой в пределах текущего цикла (но её значение может меняться в прерывании). Просто забывал добавить в определении переменной модификатор volatile.

Вот какая штука замечена в 3.20С:
Объявляю в регистре кучу флагов, например:

так вот при оптимизации выше средней запись 1 в мл бит - нормально, а очистка мл бита - генерится CLR R15. Все остальные биты - нормально...

В 3.20D этот глюк исправили

Да, слышал, но качать 50 мег, кряк искать... Влом... Когда глюк известен - он не страшен :-)
К тому же есть хороший принцип - работает - не трогай!