Это решение, пожалуй, лучше, чем предыдущее, в том плане, что

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

Рассуждения такие:
есть два момента времени: t1 - когда функция naive_table_sync начала выполнение, t2 - когда функция закончила выполнение.
В промежутке между t1 и t2 нет ниодной пишущей в metrics транзакции, так как делается SHARE блокировка на таблицу.
Если посмотреть в wiki SSI на Read Only Transactions, то оба случая вызваны тем, что читающая транзакция вызывается до коммита пишущей, что невозможно в нашем случае.
Поэтому RR аномалии похоже здесь нету (по двум причинам: serializable и share lock), т.е. похоже даже без serializable небыло бы read only аномалий.

Разве нельзя здесь RC уровень поставить?

Похоже порядок комитов может не сохраняться из-за других читающих транзакции только и поэтому в полном смысле strict serializability не гарантируется. Пример, когда из-за читающей транзакции не гарантируется strict serializability (общепринятый короткий способ записи этому есть, к примеру, SS?) такой:
-- t1
begin ... serializable;
select * from metrics;

-- t2
begin ... serializable;
update metrics set value = 222 where id = ...;
commit;

-- t3
begin ... serializable;
lock table metrics in share mode;
SELECT naive_table_sync();
commit;

-- t1
commit;

Здесь порядок коммитов такой:
t2 -> t3 -> t1
Но порядок серализуемости другой:
t1 -> t2 -> t3

> Разве нельзя здесь RC уровень поставить? Тут тонкость в snapshot-ах, а именно в том, что LOCK гарантирует, что "невидимых" взятым после него snapshot-ом инкрементов sequence не будет. Я, например, не уверен, что LOCK TABLE на RC поведёт себя правильно, это надо бы почитать/проверить (но RC меня как-то не очень интересует ;) ).