Во втором случае транзакция вообще не запускается
Любой запрос всегда исполняется в рамках некоторой транзакции. У JDBC Connection может быть включен autocommit, в этом случае драйвер будет сам автоматически посылать серверу команду commit после каждого запроса. Автокоммит вредная вещь, потому что угрожает целостности данных. Если какая-то аннотация приводит к тому, что запросы исполняются в режиме автокоммита, то это вредная аннотация и ее использовать не следует. В каких-то древних СУБД короткие транзакции были лучше для производительности, но сейчас это не актуально.
Подскажите пожалуйста, зачем задавать транзакцию для режима чтения из базы - типа

Для обеспечения transaction level read consistency.

В статье на ibm.com написана какая-то фигня. Либо автор не грамотен, либо перевод плохой, либо автор работает с какой-то экзотической СУБД.
Зачем надо начинать транзакцию, если речь идет только о чтении данных? Разумеется, этого делать не нужно.

Для statement level read consistency. Автор считает, что есть два режима - использовать транзакции и не использовать. И при использовании транзакции расходуются какие-то дорогостоящие ресурсы. Это не так. Транзакция неизбежно начинается при выполнении первого запроса, и заканчивается при commit/rollback.
Если вас не заботит качество ваших данных, то нет причин думать на тему применения транзакций, поскольку на платформе Java они могут серьезно снизить производительность

Это абсолютно неверное утверждение. Автокоммит наоборот увеличивает число транзакций и снижает производительность.

авторДля statement level read consistency

Для transaction level read consistency, я имел в виду.

Но транзакция значит в любом случае открывается и коммитится, даже для чтения?

См http://kickjava.com/src/org/springframework/jdbc/datasource/DataSourceTransactionManager.java.htm, методы doBegin и doCommit.
Кстати, тут Blazkowich писал, что классы в спринге простые и понятные. Вот отличный пример:
Data access code that should remain unaware of Spring's data access support can work with this proxy to seamlessly participate in Spring-managed transactions. Note that the transaction manager, for example DataSourceTransactionManager, still needs to work with the underlying DataSource, not with this proxy.

Make sure that TransactionAwareDataSourceProxy is the outermost DataSource of a chain of DataSource proxies/adapters. TransactionAwareDataSourceProxy can delegate either directly to the target connection pool or to some intermediary proxy/adapter like LazyConnectionDataSourceProxy or UserCredentialsDataSourceAdapter.

При этом все нужное API состоит из 3 функций: Datasource.getConnection, Connection.commit и Connection.rollback.