Правильно ли я понимаю, что в polling mode, если я не буду успевать читать TWI_RHR, я получу OVRE (Overrun Error).
Иными словами, TWI просто гонит частоту и не следит успеваю я читать или нет.

SAM7 настроен как мастер.

Спасибо.

Именно так, Флаг OVRE и предназначен для указания потери данных.

Если в случае OVRE прекратить чтение, поставив STOP в CR, то следующее чтение возвращает мусор.
При этом, если в начале чтения прочесть TWI_RHR этого (мусора) не случается. Похоже, что TWI считает, что я не прочел
RHR в предыдущем (когда был OVRE) чтении и предлагает мне его читать в последующем чтении. Тем, более, что когда я делаю
dummy read регистра состояния, там стоит RHR_READY.

Atmel сказал, что:
You can refer to AT91SAM7SE software package 'basic-twi-eeprom-project-at91sam7se-ek'. In this sample, before a read procedure is started, there actually is a dummy read operation for TWI_RHR register, in order to reset the TWI. Also you can refer to page 363 of AT91SAM7SE datasheets for TWI read operation flow.

т.е. они подтверждают, что TWI_RHR надо dummy-читать перед инициацией TWI-обмена, - "чтоб сбросить TWI".

В доке на чип этого не описано, хоть они на него и ссылаются.

Видел ли кто-то такое поведение и действительно ли имеет надо читать TWI_RHR наряду с регистром состояния, чтоб сбросить их?

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

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