Член класса/структуры типа uint8_t * или int8_t *, оптимизация?
Тут проблема не в том, что член класса char*, а в том, что запись идет в char*, и из-за strict aliasing правил - это может быть запись куда угодно, в том числе в &this. Кешировать пришлось бы любой член структуры, любого типа.

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

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

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

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

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

С restrict можно поиграть, но в чистом С++ его нет, на сколько я знаю, но можно включить расширения в gcc/clang и, возможно его можно будет использовть в плюсовом коде. Но применяйте его лучше сразу к локальному bufferу, а не к this.

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