rdm1)На методы какого уровня(DAO/Service/Facade/Controller обычно/правильно/принято ставить аннотации @Transactional ?
На Service. Потому что в большинстве случаев Service это реализация паттерна Transaction Script - посмотрите у Фаулера.
Контроллер не должен использовать несколько методов разных сервисов, потому что это уже бизнес-логика будет.
В фасаде тоже не всгеда есть смысл. Будет ситуация что в одном фасаде одни траназакции, а в другом уже другие? Зачем?
В DAO можно для подстраховки. Чтобы, например, выкидывался Exception, если нет транзакционного контекста. Но такой прощще сделать в Spring XML на все DAO методы сразу, чем писать в каждом аннотацию.

rdm2)Какой способ борьбы с LazyInitializationException для Web вы используете?
-OpenSessionInViewFilter

Гуглить "Open Session In View Antipattern" - много подробных статей с описанием проблем этого подхода.

rdm -HibernateInterceptor
-Value Bean

Не очень понял что за подходы.

rdm -Hibernate.initialize
-HQL(FETCH)

Вот эти два - однозначно. Есть интересные альтернативы например http://noon.gilead.free.fr/gilead/index.php?page=tutorial
Но они не во всех случаях подходят. Конкретно этот под GWT заточен. Но можно подсмотреть идею и написать реализацию для своего сервера.

rdm-HibernateInterceptor
тут есть пример, у меня честно говоря он не заработал, может вы подскажете почему?

Ну, это как бы и есть дефолтное поведение. На всех сервисах где есть транзакционный контекст биндится туда же и Session. Что такого особого в этом HibernateInterceptor? Это вроде и есть самый обычный подход.

rdm Ошибки нет, а в логах пишет следующее:
Not refreshing target: Bean name not specified in 'interceptorNames'.

Интерцептор нужно привязывать ко всем сервисам. interceptorNames - имена всех бинов, для которых Interceptor будет вызыватся.

rdm -Value Bean
это аналог DTO, т.е. заполняем аналогичные поля вызывает просто get()
Тут просто масса минусов. Если DTO максимально повтрояет сущности. То нужно поддерживать обе модели. Два набора схожих классов.
Точно так же никуда не девается проблема N+1, как и в Open Session In View. Т.е. вероятность схлопотать N+1 всегда есть, если девелопер не планирует правильный Fetch в каждом месте.
Могут быть другие нюансы в зависимости от приложения. Например удаление работает через Persistent коллекции.

rdmBlazkowicz, в если в методе контроллера надо вызвать методы двух разных сервисов или 3-5? Как обойтись без фасада?
Как я понял из ваших слов, тогда получается бизнес логика в контроллере?
Не понял при чем тут фасад?
Контроллер это то что обрабатывает ввод пользователя и формирует view. Логику он делегирует сервису.
Фасад это вообще подмножество методов доступных из разных сервисов. Если фасад начинает сам в одном своём методе вызывать разные методы сервисов, это снова бизнес логика не на месте.

Йуный джавистЪКстати, как сделать чтобы несколько ModelAttribute методов выполнялись в одной транзакции? Вот пример из документации:

Нет такого понятия "ModelAttribute-метод" и к транзакциям эта аннотация вообще не относится. Это просто пометку спрингу положить результат работы метода в model. Как их запустить в одной транзакции это отдельный вопрос.

Йуный джавистЪПо-видимому, никак. Для сложных контроллеров получение соединения из пула и создание хибернейт сессии будет происходить десятки раз.
Что такое "сложный" контроллер? Это тот в котором реализована логика в нарушение SRP. Контроллер не должен контролировать транзации. Он должен контроллировать ввод и сборку модели.
В том примере это вообще 2 разных методы самого контроллера. Два примера сделать одно и то же разными способами. Они вообще в одной транзакции никогда не работают