мнениеОн по третьему пункту не укладывается.
Для начала стоило бы уточнить, какой именно из третьих пунктов Вы имеете в виду.

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

мнениеМнение совпало, любой версионник для этой задачи не лучший выбор.
C кем Вы совпали, я не знаю, но не со мной. Имхо этой задаче глубоко и принципиально пофиг, версионник там или блокировочник. Ну а высказанный пункт, повторюсь, к задаче отношения не имеет (точнее, я этого отношения не вижу, готов выслушать обоснование).

мнениеПо сравнению неконтролируемыми рестартами стейтментов
Кстати, было бы любопытно увидеть пример "неконтролируемого рестарта стейтментов" для операции апдейта одной записи (наиболее типичной для данной задачи).

мнениеРестарты ловите здесь :
Имхо если не создавать ненормальных условий, не поймаю. Что я имею в виду под ненормальными условиями: например, изменение первичного ключа записи апдейтом в другом сеансе.

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

мнениеВ качестве обоснования попробуйте этот пример на серверах
поддерживающих не только RC & SERIALIZABLE. Сравните типы блокировок устанавливаемые на строки для разный уровней изоляции и целостность данных в соответствии с задачей.
Ага, похоже на то, что начали про Фому, закончили про Ерему.

В общем, суть получается такой: версионник плох тем, что в некоторых случаях ведет себя так же, как блокировочник ведет себя всегда :))