@Transactional это не часть DAO слоя. То что мы где-то ожидаем что у нас всего один вызов DAO и поэтому мы не ставим @Transactional над сервисом - это неправильное определение обязанностей DAO. DAO не имеет права определять границы транзакции, это не часть DAO абстракции. Как в общем-то и обработка оптимистических блокировок - это часть бизнес логики.
Вы пытаетесь рассказать довольно странную историю на мой взгляд. Из вашего рассказа следует примерно следующее:
- вот есть некий слой который в итоге производит манипуляции в БД (тут на самом деле уже странно, поскольку чтобы заставить хибер что-то сделать в БД до вызова flush нужно очень сильно постараться, а если мы вызываем flush явно, то это на самом деле так себе затея, к тому же это касается исключительно ваших проектов, а не вообще всех подряд, я, к примеру, принимал участие в проекте где вызывать flush() считалось западно)
- вы смотрите в код хибера (точнее спринга) и наблюдаете, что при определенном стечении обстоятельств в вашем проекте оно выкинет более-менее понятное исключение, причем нужно подчеркнуть что именно в вашем проекте и на вполне определенных версиях (здесь как в соседнем топике: 22385060 , chpasha считает что нужно следоать жавадоку, а вы его игнорируете), откуда принимаете решение что нужно делать именно так как вы увидели и несете это знание в массы, здесь есть кое-какие проблемы:
-- если DAO - это самостоятельный слой, то никаких предположений относительно того, как его будут вызывать он делать не должен, т.е. вариантов развития событий в нем всего два: принять данность как есть (т.е. использовать @Trsnsactional), либо отвергнуть (@Transactional(MANDATORY)), у него, как самостоятельного слоя, есть вполне определенная задача: всегда работать корректно
-- оба упомянутых варианта всегда работают правильно вне зависимости от того что вы там себе придумали, отличаются они только тем, насколько мы уважаем "клиента" - еще раз повторюсь: заставлять "клиента" приседать с транзакциями на ровном месте - это путь вникуда
- если у вас разработчики не понимают где начинаются бизнес-транзакции, а где заканчиваются, то это проблема исключительно разработчиков и их руководства

чет у меня есть подозрение, что если по уму делать, то "кастомных" исключений получится где-то полста (которые, к слову сказать, уже в JPA присутствуют), если не добрая сотня, но если скроить, то можно сделать исключение "хрен его знает что тут вообще произошло" и обойтись только им

А как иначе писать, если DAO - это абстракция. Если у меня в DAO не хибернейт закрытый спрингом, а что-то другое, что наличие активной транзакции не проверяет, мне нужно в DAO лепить @Transactional или нет? А если у меня в методах DAO несколько взаимодействий с БД, мне нужно лепить @Transactional или нет? А если дело касается только вашего определенного кейса, тогда почему вы несете в массу "знания" что в DAO лепить @Transactional не нужно?