Да там куча приколов помимо этого, например:



Из-за того, что транзакцию прилепить некуда в сущностях нельзя использовать поля с FetchType.LAZY, ну или вообще поля с сущностями использовать нельзя, а только идентификаторы, в следствие чего вылезают какие-то нереальные грабли, например:
- при классическом подходе повторный getItem тащит сущность из памяти, а здесь она каждый раз чистая достается, т.е. если сущность у нас мутирует, то ее придется постоянно по стэку таскать (еще и код более тщательно ревьювить)
- использование идентификаторов в полях сущностей убивает кучу возможностей, предоставляемых Criteria API, в т.ч. статическую типизацию

т.е. получается, что взяли довольно тяжелый ОРМ, у которого есть куча своих проблем, начали его использовать через Ж, и растеряли все его преимущества, которые хоть как-то нивелировали его тяжесть.

Это убивает всю идею паттерна "репозиторий"

Нет, репозиторий нужен для того, чтобы API для работы с данными (в общем случае не rdbms) не выставлять наружу, при этом "по классике" репозиторий сам присоединяется к текущей транзакции (это правда уже задача менеджера транзакций, но в целом я могу спокойно часть кода делать на ОРМ, а другую часть на JDBC (тут я не понимаю всяких бакланов, желающих все делать через native query в JPA - это неправильно)), т.е. в первом приближении я могу в приложении взять и заменить ОРМ на что-то другое, как только я начал таскать EntityManager по бизнес-логике, я сразу же теряю эту возможность (востребована ли в реальности эта возможность или нет - это другой вопрос уже).

Потому что в спецификации так написано:
jpa specificationThe PersistenceContext annotation is used for entity manager injection. The type element
specifies whether a transaction-scoped or extended persistence context is to be used, as described in section
7.6. The synchronization element specifies whether the persistence context is always automatically
joined to the current transaction (the default) or is not joined to the current transaction unless
the joinTransaction method is invoked by the application. The unitName element may optionally
be specified to designate the persistence unit whose entity manager factory is used by the container.
The semantics of the persistence context synchronization type are further described in section 7.6.1.
Section 10.5.2 provides further information about the unitName element.

т.е. чтобы в житуи EM не присоединялся к текущей транзакции нужно специально приседать, спринговая инфраструктура работает точно также, т.е. если у кого-то это не так, то это значит что в проекте творится полная Ж.

нет никакого ручного управления транзакциями - это все фантазии цветочного магазина, транзакциями должен управлять контейнер, а твой код в JTA-окружении будет падать.

Мда... чем дальше в лес тем толще партизаны. Длинные транзакции плохи в web - у клиента таймаут, а у нас еще транзакция, а связи между спрингом, JTA и длинными транзакциями нет никакой.

Конечно, ручное управление транзакциями - это дичь, если у вас не цветочный магазин, то подавляющее большинство кода должно присоединяться к уже существующей транзакции, без некого подобия менеджера транзакций этого не сделать.
От какого спринга? javax.persistence.SynchronizationType - это из какого модуля?