Sharing one SQLite connection across the process would necessarily serialize all writes from the process. It won't do anything for contention with external processes, the writes within the process wouldn't be concurrent any more.
Basically, it adds its own write lock outside of SQLite, because the pool can implement the lock in a less annoying way.
SQLite's lock is blocking, with a timeout that aborts the transaction. An async runtime can have a non-blocking lock that allows other tasks to proceed in the meantime, and is able to wait indefinitely without breaking transactions.
What's the benefit of this over just doing PRAGMA busy_timeout = 0; to make it non-blocking ?
After all, as far as i understand, the busy timeout is only going to occur at the beginning of a write transaction, so its not like you have to redo a bunch of queries.
Basically, it adds its own write lock outside of SQLite, because the pool can implement the lock in a less annoying way.