Is there a benefit in wrapping get request handlers in transaction (postgres)

Let's say we have a get request handler that does the following:

knex.transaction(async (trx) => {
  const user = await knex.select(*).from('user').where('id', 1).transacting(trx);
  const roles = await knex.select(*).from('roles').where('iser_id', 1).transacting(trx);
  return {...user, roles}
})

By default transaction level is read committed.

Based on postgres docs:

Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes after the first SELECT starts and before the second SELECT starts.

Is there a benefit in using transaction with read committed isolation level if we don't use SELECT FOR SHARE or Repeatable Read+ isolation level? Wouldn't omitting transaction produce the same result(with same issues):

  const user = await knex.select(*).from('user').where('id', 1);
  const roles = await knex.select(*).from('roles').where('user_id', 1);
  return {...user, roles}