Seems that sqlite3_finalize was protected with the GIL previously and the check for PyErr_Occurred makes me thing that some callback or similar could end calling Python code. Could you confirm if this is indeed safe?

Hm, sqlite3_finalize was called outside of the GIL previously, and it still is. Previously, we would release/acquire GIL before/after every SQLite API call; now we release, do all SQLite API calls, then acquire.

Previously

1. allow threads (unlock GIL), prepare statement, disallow threads (lock GIL)
2. raise exception and bail on error
3. unlock GIL, execute SQL statement (sqlite3_step), lock GIL
4. raise exception and "fall through" on error
5. unlock GIL, finalise statement (release resources, etc.), lock GIL
6. raise exception, unless sqlite3_step already did, on error => this is the extra PyErr_Occurred

Since sqlite3_finalize will pass on the error set by sqlite3_step, there is no need to check for errors after stepping. We only need to do it after finalising the statement.

Now

1. unlock GIL, create, execute, and finalise SQL statement, lock GIL
2. raise exception and bail on error

Can sqlite3_finalize raise Python errors on its own (via cleanups, callbacks or otherwise)?

Not the way we currently use the SQLite API. If we'd added SQLite profile support, sqlite3_finalize (and other API's) would invoke our _trace_callback() C callback with argument type set to SQLITE_TRACE_PROFILE. We could add an assert(type != SQLITE_TRACE_PROFILE) and a comment about this to _trace_callback().