Why is the term "unit of work" so important and why does JDBC AutoCommit violate this pattern?

I am study how Spring handle transaction and I can't give a precise answer to the following question founded on the study material:

Why is the term "unit of work" so important and why does JDBC AutoCommit violate this pattern?

So, I know that the unit of work is a desing pattern that maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.

So I know that with Spring JdbcTemplate I can have something like this:

try {
    conn = dataSource.getConnection();
    conn.setAutoCommit(false);
    …
    conn.commit();
} catch (Exception e) {
    conn.rollback();
    ...
}

where conn.setAutoCommit(false); is a programmatic transaction demarcation (because in this case I am programmatically declaring my transaction that is all that happens between the previous operation and the final commit operation).

So, from what I understand (but it can be wrong). If instead false I have:

conn.setAutoCommit(true);

each individual SQL statement between this statment and the final commit is is treated as a transaction and is automatically committed right after it is executed. So, in this way, I will have n committed SQL statment and it is contrary to the logic of unit of works that maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.

Is it reasoning correct or am I missing something?