Is there any side effect if select statements are wrapped in BEGIN TRAN ... COMMIT?
The answer depends on what isolation level your .NET project is setting when it accesses SQL Server.
If it's READ COMMITTED (the default), then there's not really any additional overhead (other than the additional BEGIN TRAN and END TRAN statements being executed).  You might think additional information would be written to the transaction log, but transactions don't really &quot;begin&quot; until something happens that needs to be logged.  I've written about this here: Transactions Don't Start At BEGIN TRAN
If you're using the SERIALIZABLE isolation level, you could get burned by the fact that those SELECTqueries will hold the locks they take for the duration of the transaction.  This could be happening without you realizing it if you're using TransactionScope in your .NET project, since that uses SERIALIZABLE by default (see my blog post for a demo: TransactionScope Considered Annoying).
I'd say all in all, if the default isolation level is being used, there's not much downside to leaving things the way you've described.  You'll want to be careful about the isolation levels though.