Why does this seek on BIGINT col have extra constant scan, compute scalar, and nested loops operators?

SELECT thing, 
       sql_variant_property(thing,'basetype') AS basetype,
       sql_variant_property(thing,'precision') AS precision, 
       sql_variant_property(thing,'scale') AS scale
FROM (VALUES (2147483648)) V(thing)

Shows you that the literal 2147483648 is interpreted as numeric(10,0). This behaviour pre-dates the introduction of the bigint in SQL Server (2000).

There is no syntax to indicate that a literal should be treated as bigint - adding an explicit CAST is the best solution. The article Dynamic Seeks and Hidden Implicit Conversions discusses the rest of the apparatus in the plan.

The plan itself shows that the nested loops has a seek predicate on

Seek Keys[1]: Start: [tempdb].[dbo].[Table1].col1 > Scalar Operator([Expr1005]), 
                End: [tempdb].[dbo].[Table1].col1 < Scalar Operator([Expr1006])

You can use an extended events session on query_trace_column_values to see that these are as follows.

The XML in the plan also shows this

  <DefinedValue>
    <ValueVector>
      <ColumnReference Column="Expr1005" />
      <ColumnReference Column="Expr1006" />
      <ColumnReference Column="Expr1004" />
    </ValueVector>
    <ScalarOperator ScalarString="GetRangeWithMismatchedTypes((2147483648.),NULL,(6))">
      <Intrinsic FunctionName="GetRangeWithMismatchedTypes">
        <ScalarOperator>
          <Const ConstValue="(2147483648.)" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="NULL" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="(6)" />
        </ScalarOperator>
      </Intrinsic>
    </ScalarOperator>
  </DefinedValue>

This does not mean that it is literally doing a comparison < null rather

The range boundary expressions use NULL to represent 'unbounded' at either end. _(Source)

So the net effect is that your query predicate of b.col1 > CAST(2147483648 AS NUMERIC(10, 0)) still ends up with a seek against b.col1 > CAST(2147483648 AS BIGINT)

Does it affect bound parameters to prepared statements (from jtds JDBC) as well?

I haven't used jtds JDBC but I presume it allows you to define parameter datatypes? If so just make sure the parameters are the correct datatype that match the column (bigint) so there's no need for SQL Server to deal with mismatched datatypes.

In relation to my question about JDBC prepared statements. jTDS uses sp_prepare/sp_execute (in default prepareSQL=3 mode).

With the following query (source):

use database
select
    cp.objtype, st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where cp.objtype = 'prepared' and st.text like '%TABLE%'

I can see the prepared statement as issued by JTDS, and it does declare the variable as (@P0 bigint)... as expected.

So this is all good and I need to remember that when trying out the execution plans that it is better to actually define local typed variables instead of replacing them with literals (and/or using sp_execute to tap into the cached execution plan).