Begin Transaction when Stored Procedure Calls itself

I am experiencing occurrences of long blocking/deadlocks in a system I support.

One of the stored procedures this system calls often has the following code:

begin transactionbegin tryexecute sp_executesql @compare_var, @ParmDefinition, @user_id_temp = @user_id_temp OUTPUT
		commit
	end try
	begin catch
		select @err_num = ERROR_NUMBER()
		if @err_num = 1205
		beginrollbackexec get_next_record_sp @input_xml
		end
	end catch

In the code above, I noticed that a rollback is only being performed if the error is 1205 (deadlock); if an error occurs that isn't identified as a deadlock, the commit nor rollback will be performed.

A few questions:

 - The query being executed by 'sp_executesql' is a SELECT statement only - no insert/update/deletes.  In this situation, what are the benefits of putting a SELECT statement within a begin transaction? (IE - it seems like there may be situations where a transaction is being left open when a transaction is not even necessary/beneficial in this instance).

- What happens if a begin transaction is performed and the stored procedure never ends the transaction (either via commit or rollback)?  Will an implicit commit occur when the stored procedure completes?

Thanks.